Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EMF Compare/New and Noteworthy/3.1.0
- 1 User Interface
- 2 Core changes
- 3 Contributors
- 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
- With a read-only side (comparison with EGit)
Expand group on double-click
- In the viewer, a double-click on a group now expands it to the second level of depth.
- 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)|
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.
- Items can be displayed as list or tree (change representation via toolbar).
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.
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)
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
- With filter inactive
- 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).
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
- After: With specific handling of UML Opaque Action
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.
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