Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

EMF Compare/New and Noteworthy/3.1.0

User Interface

Contextual menu on differences

  • If you do a right-click on a difference in the viewer, a contextual menu now offers you to merge the selected difference. These actions are the same than those in the toolbar.
    • With local models

EMFCompare ContextualMenu Differences.png

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

EMFCompare ContextualMenu Differences 02.png

Expand group on double-click

  • In the viewer, a double-click on a group now expands it to the second level of depth.

EMFCompare Group DoubleClick 01.png EMFCompare Group DoubleClick 02.png

Conflict labels

  • In the viewer, the conflicts group items have been enhanced. The label shows the total number of conflicted differences under the group and the number of conflicted differences still unresolved. When all differences under a group have been resolved, the group label switch as resolved and its icon turned into gray.
Before After (unresolved) After (resolved)
EMF Compare Conflicts Label Old.png EMF Compare Conflicts Label New.png EMF Compare Conflicts Label New 02.png

Logical Model View

The new EMF Compare Logical Model View allows users to see, for a given model (or set of models), the resulting logical model computed by EMF Compare.

  • When you click on a model in the Package Explorer view or the Project Explorer view, or the focus is on an opened model editor, then the Logical Model view shows this model and all models linked with this one.

EMF Compare LogicalModelView.png

  • Items can be displayed as list or tree (change representation via toolbar).
List Tree
EMF Compare LogicalModelView List.png EMF Compare LogicalModelView Tree.png

Placeholders for not loaded fragments

When a model is split into fragments, and only some of them have changes, the structure merge viewer (SMV) and the content merge viewers (CMV) display the models involved in the comparison but don’t display the fragments that have no changes.

If a change (x) is detected in a fragment (B), and this fragment is a child of another fragment (A) that has no changes, then (A) won't appear in the SMV and the CMV's. As a result, users will think (B) is the root of the global model.

To avoid this, the idea is to display intermediate node(s) (represented as [...]) in order to show to users that it exists something (fragments, i.e. a parts of models) between/above the changes.

Without and with items for not loaded fragments

Core changes

Handle FeatureMap differences

  • Detects addition/deletion of a value for a given key of a map.
  • Detects key change for a given value of a map.
  • Detects move of a value inside a map (the key stays the same).
  • Detects move of a value inside a map (the key changes).
  • Detects move of a value from a map to another (the key stays the same).
  • Detects move of a value from a map to another (the key changes).
  • Add a new filter to hide feature map changes that has related reference changes. With EMF Ecore models, features of type EFeatureMapEntry are linked with EReferences via ExtendedMetaData (see the EMF Library example for more details). Here is a partial view of the EMF Ecore Library model showing a feature of type EFeatureMapEntry (people) and its EReferences associated (employees, borrowers)
EMFCompare Library FeatureMap 04.png

So, for example, the addition of a new Employee in the library will modify the reference employees but also the map people. With EMF Compare, the comparison will detect two changes, one on the employees reference and one on the people map. These two differences are equivalent. If you merge one, the other will be merged too. The filter allows to hide the changes on the map, and so reduce the number of changes displayed in the viewer.

    • With filter active

EMFCompare Library FeatureMap 01.png

    • With filter inactive

EMFCompare Library FeatureMap 02.png

    • With filter inactive, and a difference on the map selected: the associated difference on the reference is highlighted in green (this mean that in case of merge, the difference on the reference will be merged too).

EMFCompare Library FeatureMap 03.png

Three-way merging multi-line String attributes

  • EMF Compare now checks whether concurrent changes applied to multi-line String attributes can be merged automatically using a three-way line-based merge algorithm, as used in Git. Only if such concurrent changes cannot be merged automatically, EMF Compare will raise a conflict. Otherwise, changes to multi-line String attributes will be merged automatically.

Improved Handling of UML Opaque Action, Behavior, and Expression Body Changes

UML opaque actions, behaviors, and expressions have a multi-valued language attribute and a multi-valued body attribute, which are logically connected through the indices of their values, comparable to a map of languages (key) and bodies (values). To accommodate for this logical connection, we introduced specific handling of changes applied to values of the language and body attribute of UML opaque actions, behaviors, and expressions. EMF Compare now detects accordingly changes of body values of a language, as well as additions, deletions, and moves of language/body value pairs. Furthermore, this connection is also respected for the detection of conflicts and for merging to keep the language/body map consistent.

  • Before: Without specific handling of UML Opaque Action
 EMF Compare OpaqueElementBodyChanges Before.png
  • After: With specific handling of UML Opaque Action
 EMF Compare OpaqueElementBodyChanges After.png

Renaming of resources' fragments

The renaming of resources' fragments are now handled by EMF Compare, in case of shared models with git. In this case a difference will be display in the comparison editor allowing you to accept or reject the change. Furthermore, in case of a Papyrus diagram & model renaming (renaming all .di, .notation and .uml files), the 3 differences will be accepted or rejected together, in order to maintain the consistency of the models.

EMFCompare ResourceNameChange.png


The following developers and contributors worked on this release:

  • Alexandra Buzila
  • Arthur Daussy
  • Axel Richard
  • Cédric Brun
  • Laurent Delaigue
  • Laurent Goubet
  • Maximilian Koegel
  • Michael Borkowski
  • Mikaël Barbero
  • Philip Langer
  • Stefan Dirix

Back to the top