Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316177

Summary: Dangling references exist after parsing XMI documents that reference other XMI documents
Product: [Modeling] EMF Reporter: Brendan <bberry>
Component: cdo.coreAssignee: Project Inbox <emf.cdo-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: saulius.tvarijonas
Version: 4.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Brendan CLA 2010-06-08 13:30:21 EDT 
I am using a model that includes references that are spread out across multiple documents.  As part of an Import/Export feature I serialize the documents to XMI by manually transferring contents of CDO resources into XMI resources.  After saving the XMI resources to disk I can visually inspect them and see that the cross-document references are syntactically correct.  I can then read those files back into a new ResourceSetImpl using XMIResourceFactory and see that the model is correctly structured and all references are maintained.

However, if I attempt to load the same XMI files into the CDO resource set -- the value returned by CDOTransaction.getResourceSet() -- then I find that some of the resources are empty.  Furthermore, if I attempt to save the resources at this time then I receive exceptions indicating that some EMF objects are not contained in resources.  This holds true even if I use another ResourceSet to first load the XMI files and then transfer the contents of those resources, because as soon as I add an object to the CDO resource set the model will attempt to resolve external resources.

The resources that wind up empty are always the same for me in my test.  Three of the five resources appear to load correctly.
Comment 1 Brendan CLA 2010-06-08 13:32:09 EDT 
As an important note, I have additionally tried setting the extension mapping for the CDO resource set to use an XMIResourceFactory before loading.
Comment 2 Brendan CLA 2010-06-08 13:34:20 EDT 
It may be useful to mention that some of the files in this test case are GMF Diagram documents.
Comment 3 Brendan CLA 2010-06-15 15:04:48 EDT 
I "resolved" my situation through the following steps:

1.  Parse the XMI resources into a basic ResourceSetImpl (without CDO backing)
2.  Create a master XMI resource in the same resource set
3.  Move the contents of each parsed XMI resource into the master resource
4.  Invoke EcoreUtil.resolve() to update the URIs of the elements so that they all officially "live" in the master resource
5.  Create a second master resource in the CDO resource set
6.  Copy the contents of the XMI master into the CDO master
7.  Invoke EcoreUtil.resolve() to update the URIs of the elements again
8.  Create CDO resources to represent the original XMI resources (this is optional of course)
9.  Transfer the contents of the CDO master into the individual CDO resources
10.  Invoke EcoreUtil.resolve() one last time

The resulting resource set has no duplicates and no dangling references.  All cross-document references appear to be correct.
Comment 4 Eike Stepper CLA 2010-06-29 04:54:38 EDT 
Rebasing all outstanding 3.0 problem reports to version 3.0.1
Comment 5 Eike Stepper CLA 2010-07-07 07:10:31 EDT 
Fixing wrong bug version.
Comment 6 Eike Stepper CLA 2011-06-23 04:27:04 EDT 
Moving all open problem reports to 4.0
Comment 7 Eike Stepper CLA 2012-06-05 07:28:59 EDT 
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems.

Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!
Comment 8 Eike Stepper CLA 2012-08-14 22:55:12 EDT 
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Comment 9 Eike Stepper CLA 2012-10-31 09:54:44 EDT 
No activity or ping here for years. Please reopen this bug if you feel a need.