[
https://issues.jboss.org/browse/TEIIDDES-2834?page=com.atlassian.jira.plu...
]
Barry LaFond commented on TEIIDDES-2834:
----------------------------------------
[~sqtran] The Model Project name is an Eclipse resource name and probably shouldn't be
used as a GIT repo name. On the one hand it makes sense for simplicity-sake, but in this
case, your repo will be containing an eclipse ".project" and other eclipse
project-related files. For development, typically Ecilpse and/or Maven plugins, for
instance, are contained within a parent folder in a repo. Any chance you could adopt at
least one more layer in each repo to maintain this eclipse project integrity?
Note also the Teiid VDB archive contains XMI files which are not deployed as runtime
metadata. That metadata is included in the VDB via 1234567890.INDEX files. 1 per model.
The vdb.xml also contains checksum values for each model to use for determining
"sychronization". The may be one of the reasons you have to force/edit the view
model & save and force re-synch. The vdb.xml also has a backing schema... so in the
end, hand-editing the vdb.xml file is not recommended.
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)