Community
Participate
Working Groups
1- An object 'P' references an object 'B'. An object 'C' is added and it is referenced by 'P' (instead of 'B'). 2- The add of 'C' is merged (copied) into the right model. 3- In the same session, the update reference change is merged (copied) into the same model. All the differences seem to be merged. The emf compare editor is closed. 4- The emf compare editor is reopened. A difference is detected on the reference because it is the reference to the left 'C' which has been merged and no to the copy of it. Note 1: If the step 2 and 3 are executed in two different sessions (before and after a close and open editor), the copy succeed. Note 2: The only merge of the update reference change doesn't involve the merge of the model element change. So, the behavior is not the same than the merge of a model element change.
Created attachment 202182 [details] Step 1
Created attachment 202183 [details] Step 2
Created attachment 202184 [details] Step 3
Created attachment 202185 [details] Step 4
Note 2 (bis): And not the same behavior as the merge of ReferenceChangeLeftTarget or ReferenceChangeRightTarget which would reference model elements referenced by a ModelElementChange.
Created attachment 202210 [details] The original UML model (technical ids)
Created attachment 202211 [details] The modified UML model (technical ids)
I am using Emfcompare 1.3M4 and I think I've got this problem. Is there any progress with this bug?
Per, I fixed this and can no longer reproduce the issue with the attached models. Could you try this update site (https://hudson.eclipse.org/hudson/job/emf-compare-master/136/artifact/EMF.Compare.p2.repository/) for the latest nightly build of EMF Compare and tells us if you still encounter the issue? If you do, could you provide us with sample models that trigger this problem? In the mean time, a unit test with the first provided models has been added to master.
I've updated to the mentioned update site 2 ACTIVE org.eclipse.emf.compare_1.3.0.v20120127-1011 112 ACTIVE org.eclipse.emf.compare.diff_1.3.0.v20120127-1011 128 ACTIVE org.eclipse.emf.compare.match_1.3.0.v20120127-1011 Perhaps it is not the same problem(?), in the forum entry 'http://www.eclipse.org/forums/index.php/t/277609/' I described my situation. I attach the Activator.java and the ecore Model. The output is 0. Go 1. Compare 2. Add & Assign City 3. Compare Reference city in Testname1 changed from null to City? City? has been added 4. Merge 5. Compare 6. Root1 Persons: 21488880 [City: 241547128 / file:/.../de.pelle7.env/file1.nop], Cities: 241547128, 7. Root2 Persons: 206180776 [City: 241547128 / file:/.../de.pelle7.env/file1.nop], Cities: 938487466, Finished! The city is duplicated in the merge step but the reference in the 2nd person instance is to the city instance from the first model instance and not to the newly created one.
Created attachment 210239 [details] simple ecore model and java code which creates two instances
Hi, I indeed reproduce the issue with these models. I am fairly certain that the issue arises because your models are CDO enabled. The same example with "regular" models (which elements inherit from EObject and not CDOObject) works smoothly. I will try and track down why EMF Compare cannot properly handle CDO-enabled models, re-opening this bug until then.
The problem was neither CDO nor EMF Compare. You are not using the proper APIs to launch the comparison (granted, it is possible to use the code you use, but not that way :)). You should not instantiate the MatchEngine and DiffEngine manually, but use the MatchService and DiffService that act as a facade to hide the complexity. In short, you have to change : private DiffModel check(Root root1, Root root2) { MatchModel matchModel = new GenericMatchEngine( ).contentMatch(root1, root2, null); DiffModel diffModel = new GenericDiffEngine().doDiff(matchModel); showDiffs(diffModel); return diffModel; } To private DiffModel check(Root root1, Root root2) { MatchModel matchModel = MatchService.doContentMatch(root1, root2, null); DiffModel diffModel = DiffService.doDiff(matchModel); showDiffs(diffModel); return diffModel; }
Great, works fine in the M5 version.
