EMF Compare/New and Noteworthy/3.2.0

User Interface

Sirius integration

EMF Compare 3.2.0 includes an _experimental_ support for Sirius diagram comparisons. All Sirius-based modelers should be supported by this, but we've notably tested this against EcoreTools for now. The goal of this support is to allow for the diagram comparisons to be displayed in their own editor instead of being shown in a default tree editor.

For example, this is what the comparison will look like for ecore diagrams:

And this is what would be shown for a custom DSL (here, a family DSL):

Context menu on model elements and resources

• If you do a right-click on a model element or a resource in the viewer, a new context menu now offers you to merge all non-conflicting differences that are contained in the selected model element or resource with one click. Note that the behavior on which differences are being merged is defined according to the specification of merging non-conflicting differences.
  • With local models

• • With a read-only side (comparison with EGit)

Contextual Tooltips

The tooltips are now contextualized. Each button has a specific tooltip for each case. The tooltip now displays the best information depending of the context. It tells exactly which object will be affected by the merge action, and which model will be modified (or not) by the merge action.

Core changes

Support UML dangling stereotypes in comparisons and merges

A new type of ResourceAttachmentChange have been created in the org.eclipse.emf.compare.uml2/model/uml2compare.ecore metamodel. It is DanglingStereotypeApplication.

No specific merge work is doing on DanglingStereotypeApplication. That means DanglingStereotypeApplications is mergeable from left to right or right to left (and accept/reject) without specific control. Thus, the dangling references could be merged into a "clean" model and make it "dirty".

As a ResourceAttachmentChanges, DanglingStereotypeApplications are displayed under MatchResources.

Scalable Conflict Detector

Conflict detection used to be implemented with an algorithm in O(n²), n being the number of differences.

Of course, on large models with many differences, this algorithm didn't scale properly.

EMFCompare 3.2.0 introduces a new conflict detector that performs better and scales better.

Given the youth of this new conflict detector, it is not active by default. In order to use it, users must select it in:

Preferences > EMF Compare > Engines > Tab 'Conflict'

Ignore changes in Papyrus di-files

In older versions of Papyrus, additional information, such as the open tabs, are stored in the di-files of the Papyrus model. Users consequently manipulate the di-file "unconsciously" by opening or closing diagrams and may be faced with unclear and rather unimportant merge conflicts during a git merge of Papyrus models.

We now ignore remote changes of the di-file during the comparison and merge.

We introduce a post processor that removes conflicts among changes that affect model elements located in the di-file. If the user opts to include those changes in the comparison anyway, he/she still can deactivate the "Ignore Papyrus Di-files Post-Processor" in EMF Compare Preferences.

Comparisons and merges involving resource changes

The notion of ResourceLocationChange introduced in a previous version of EMFCompare has limits as soon as resources with several roots are involved in comparisons. Actually, ResourceLocationChange is only relevant for resources with one root, which is limited and wrong. Consequently, we introduce the notion of ResourceAttachmentChange with kind MOVE. ResourceLocationChange is consequently deprecated.

This change also implies to modify the way we handle the matching of resources. Before, when using ResourceLocationChanges to manage the renaming or move or resources, we had to be able to match 2 resources that did not have the same name or path. Now, with the use of ResourceAttachmentChange/MOVE, we don't have to artificially match 2 resources located in different places. This is especially more robust when working with git repositories, since in this case comparisons can be handled by matching resources according only to their path. When dealing with EGit, 2 resources with different paths will never be matched. This does not prevent a ResourceAttachmentChange of kind MOVE to be created, since such a change is attached to the moved root element.

IMPORTANT RESTRICTION Please note that this specification only supports moves of root nodes for EGit comparisons. Such moves will not be properly detected for local comparisons, since the paths of resources will then always be different.

However, this solution is more robust, more powerful since it allows to manage resource with several roots (which is the case of GMF notaionf resources for instance), and also more elegant since it does not break the general contract of diffs like ResourceLocationChange did.

This change is accompanied by EGit-specific and papyrus-specific classes registered through extension points:

• EGitPostProcessor in project org.eclipse.emf.compare.egitis used to actually create the ResourceAttachmentChange with kind MOVE
• PapyrusResourceAttachmentChangeMerger in project org.eclipse.emf.compare.diagram.ide.ui.papyrus is used to merge papyrus-specific empty resources, which contain no model element to which any diff can be attached. This is necessary to properly create or delete empty resources such as *.di files, or sometimes empty *.notation files also.

Contributors

The following developers and contributors worked on this release:

• Alexandra Buzila
• Arthur Daussy
• Axel Richard
• Cédric Brun
• Laurent Delaigue
• Laurent Goubet
• Mathieu Cartaud
• Michael Borkowski
• Philip Langer
• Stefan Dirix