Eclipse Community Forums: Compare » NPE in ReferenceChangeMerger

Help

Home

Home » Modeling » Compare » NPE in ReferenceChangeMerger

Show: Today's Messages :: Show Polls :: Message Navigator

NPE in ReferenceChangeMerger [message #1859507]

Mon, 12 June 2023 22:39

Ernesto Posse

Messages: 438
Registered: March 2011

Senior Member

Hi.

I have run into trouble with using EMF Compare (actually Papyrus Compare) +EGit on some UML models. The scenario is this:

We have a simple UML model (with a custom Profile) on a git repo. In one branch (let's call it "a") there are some elements, including a UML Class C, and in the other branch (let's call it "b") we have the same elements, but with some conflicting changes in Class C, and a new Class D with an InterfaceRealization whose "supplier" is a reference to a UML Interface I stored in a separate resource, so the Interface object is a proxy.

When I try to merge "a" onto "b", there are no problems. The conflict is detected, we can open the Merge Tool and resolve the conflicts. But when I try to merge "b" onto "a", I get an NPE.

The NPE occurs in the internalCheckingOrdering method of ReferenceChangeMerger, more precisely when getting the "newValue", i.e. the left of the valueMatch:

	private void internalCheckOrdering(ReferenceChange diff, boolean rightToLeft) {
		final EStructuralFeature feature = diff.getReference();
		final EObject value = diff.getValue();
		final Match match = diff.getMatch();
		final Comparison comparison = match.getComparison();
		final Match valueMatch = comparison.getMatch(value);

		final EObject sourceContainer;
		final EObject targetContainer;
		final EObject newValue;
		if (rightToLeft) {
			sourceContainer = match.getRight();
			targetContainer = match.getLeft();
			newValue = valueMatch.getLeft();
//...

The NPE occurs in the last line shown here, since "valueMatch" is null.

Here "feature" is the "supplier" reference from the InterfaceRealization to the Interface I and "value" is the Interface I proxy object.

This "valueMatch" variable is null because "value" is a proxy object (the UML Interface I proxy), and apparently there is no "Match" object created for this proxy. After going through the entire process with the debugger, I noticed that during the "Match" phase, a MatchSpec is created for the new Class D where (before pre-merge) the "left" is null and the "right" is D, and has a sub-match for its InterfaceRealization which has a null "left" and the appropriate object on the "right", but this latest MatchSpec for the InterfaceRealization *doesn't* have any submatches. In particular, there is no sub-match for the Interface proxy.

So I have a couple of questions:

1) During the Match phase, aren't submatches for proxy objects supposed to be created? If not, why?
2) Why does this occur only when merging in one direction but not the other? The exception occurs on a path that calls copyRightToLeft (org.eclipse.emf.compare.merge.AbstractMerger.copyRightToLeft(Diff, Monitor)), during the pre-merge (org.eclipse.emf.compare.ide.ui.internal.logical.EMFResourceMappingMerger.doMergeForDiff(Monitor, Set<URI>, Diff, IDiffRelationshipComputer)) but the exception doesn't occur in the "a" to "b" case because copyRightToLeft is not called in that case, and while there is a copyLeftToRight method, apparently is not called at all on pre-merge! Why the asymmetry? Isn't this a bug?

Thanks

PS: I'm using an oldish version of EMF Compare (3.3.11.202005260905) but looking at more recent versions it looks like they could suffer from the same issue. I should also mention that I'm using EGit to initiate the merge, but that doesn't look like it has anything to do with the problem, as far as I can tell.

[Updated on: Tue, 13 June 2023 21:29]

Report message to a moderator