[
https://issues.jboss.org/browse/TEIIDDES-2834?page=com.atlassian.jira.plu...
]
Steve Tran commented on TEIIDDES-2834:
--------------------------------------
No, I didn't check in the .project files or any of the Eclipse metadata. Typically,
when I check out any project from GIT, the folder that I check it out into doesn't
matter because all the files inside of it never reference anything absolutely. It's
usually ../../xyz for example.
I'm in a weird situation now because I created a VDB project in a folder called
steve_project. In the VDB file, there are references to "steve_project" as the
root folder. I've committed this work into GIT under a repo that may or may not have
the same name. In this case, it's called VDB_Project1. When someone else comes and
clones VDB_Project1, the name that they name their local folder on their system MUST be
"steve_project", or else all the internal references are broken.
I fully agree with you that hand editing any of these generated VDB files/xml is hacky.
As it turns out, my workaround leads to an undeployable VDB, so it looks like everyone
will need to use "steve_project" as their project folder from now on.
Local project name baked into VDB
---------------------------------
Key: TEIIDDES-2834
URL:
https://issues.jboss.org/browse/TEIIDDES-2834
Project: Teiid Designer
Issue Type: Bug
Environment: Red Hat JBoss Data Virtualization 6.2.4 on EAP patched to version
6.4.6, on Oracle Linux 6
JBoss Developer Studio 8.1.0GA with Teiid Designer
9.0.6.Final-v20160316-1409-B1242 org.teiid.designer.feature.feature.group JBoss by Red
Hat, Inc.
64-bit Windows 7 environment
Reporter: Steve Tran
With any source control tool, if I clone/checkout a VDB project, the name of the project
must match the name it was created with. All the internal references are using an
absolute path with the original project name as the root. This makes VDB projects less
portable because someone who comes in and does a git clone <git url>
<their_name> will have an unstable project unless they change <their_name> to
what the VDB is hard-coded to.
I'm seeing if there's a workaround, such as renaming the internal references, but
it looks like a lot of work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)