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

Bug 355897

Summary:

Bad copy of the merge of an UpdateReference difference

Product:

[Modeling] EMFCompare

Reporter:

Cedric Notot <cedric.notot>

Component:

Core

Assignee:

EMF Compare <emf.compare-inbox>

Status:

CLOSED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

laurent.goubet, Per.Sterner, tino_milschewski

Version:

1.3

Target Milestone:

---

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
Step 1	none
Step 2	none
Step 3	none
Step 4	none
The original UML model (technical ids)	none
The modified UML model (technical ids)	none
simple ecore model and java code which creates two instances	none

Description Cedric Notot

2011-08-25 17:33:40 EDT

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.

Comment 1 Cedric Notot

2011-08-25 17:34:35 EDT

Created attachment 202182 [details]
Step 1

Comment 2 Cedric Notot

2011-08-25 17:35:07 EDT

Created attachment 202183 [details]
Step 2

Comment 3 Cedric Notot

2011-08-25 17:35:53 EDT

Created attachment 202184 [details]
Step 3

Comment 4 Cedric Notot

2011-08-25 17:36:31 EDT

Created attachment 202185 [details]
Step 4

Comment 5 Cedric Notot

2011-08-26 03:48:35 EDT

Note 2 (bis): And not the same behavior as the merge of ReferenceChangeLeftTarget or ReferenceChangeRightTarget which would reference model elements referenced by a ModelElementChange.

Comment 6 Cedric Notot

2011-08-26 03:49:13 EDT

Created attachment 202210 [details]
The original UML model (technical ids)

Comment 7 Cedric Notot

2011-08-26 03:49:53 EDT

Created attachment 202211 [details]
The modified UML model (technical ids)

Comment 8 Per Sterner

2012-01-20 11:27:39 EST

I am using Emfcompare 1.3M4 and I think I've got this problem. Is there any progress with this bug?

Comment 9 Laurent Goubet

2012-01-27 08:49:28 EST

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.

Comment 10 Per Sterner

2012-01-29 06:52:38 EST

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.

Comment 11 Per Sterner

2012-01-29 06:56:10 EST

Created attachment 210239 [details]
simple ecore model and java code which creates two instances

Comment 12 Laurent Goubet

2012-01-30 10:50:16 EST

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.

Comment 13 Laurent Goubet

2012-01-30 11:10:34 EST

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;
	}

Comment 14 Tino Milschewski

2012-02-01 06:05:42 EST

Great, works fine in the M5 version.