Skip to main content
Jump to: navigation, search

Difference between revisions of "EMF Compare/Release Review/3.0.0"

(Commiter Diversity)
m ( moved page EMF Compare/ReleaseReview/Luna to EMF Compare/Release Review/3.0.0)
(No difference)

Revision as of 05:46, 6 October 2014

Luna Release Review - EMF Compare 3.0

Laurent Goubet (

Release Review : May 2014

Communication Channel : eclipse.modeling.emf newsgroup

Process Documentation :

Project Plan :

New & Noteworthy

User experience overhaul

The EMF Compare Graphical User Interface (GUI) has been rethought in order to make the workflow easier for the user and reduce the possible confusion induced by the action placements.

Action placement

The first visible change is that we moved the "merge" actions from the bottom pane to the very top of the comparison editor. These actions react to and operate on selections in the top panel (the structural view of the differences), which was hard to understand when they were located just above the bottom panel of the editor (which displays the content of the compared versions). This move can be seen in the following two screenshots.

EMF Compare 2.1.0 EMF Compare 3.0.0
EMF Compare 2.1 UI actions.png EMF Compare 3.0 UI actions.png

Impact preview

Also visible in the above two screenshots is the previsualization of the impacts of a merge operation. All differences linked in one way or another with the currently selected one are highlighted in a different color depending on how they are related. In the above example, we have selected the difference on Magazine that's been made on the right side : we added Periodical as a super-type. This conflict with the removal of Periodical from the left side, highlighted in a light-red color, and depends on the fact we actually added the Magazine Class in the right side before we could add a super-type to it (highlighted in a light-green color).

This previsualization depends on the direction we are expecting to merge the difference, visible as the leftmost button in the editor's toolbar :

EMF Compare 3.0 UI merge direction.png

For example, if we are going to merge the change to pages (we added the feature pages inside a new Class Magazine on the left side), we can actually do two actions on it. We can either copy the change from the left side to the right, thus adding the pages feature to the right version, or copy it from the right to the left, thus reverting the difference in the left model, deleting the pages feature from it. Both actions have consequences, but not the same in both directions.

If we copy from the left to the right side, what we want is to "add the pages feature to the Magazine class in the right version". However, Magazine is itself a new class, so adding a feature to it requires us to also merge the addition of the class. Thus, the addition of Magazine gets highlighted when we select this direction for previsualization.

EMF Compare 3.0 UI impact LtR.png

On the contrary, if we decide that we want to copy this change from the right to the left, we actually want to reject the addition of the pages features. This makes the change of this feature's type to "EInt" obsolete as well since it was a requirement for it, much the same as the addition of the class Magazine is a requirement for the addition of the pages feature.

EMF Compare 3.0 UI impact RtL.png

Progress feedback

We previously used a background job while executing the comparison, leaving the user with an empty comparison editor until we could display the final result. Though we still won't display a partial comparison during its computation, visual feedback is now provided to the user as the comparison progresses from within the comparison editor itself.

EMF Compare 3.0 UI progress.png

Textual fallback

A comparison failure would previously be unrecoverable, leaving the user with an unhelpful "error" editor and the errors logged in the Eclipse error log. A comparison failure will now be displayed within the editor itself, along with a textual comparison of the files.

EMF Compare 3.0 UI fallback.png


The number of extension points available to customize the different aspects of EMF Compare has been greatly expanded, allowing users to override or customize all of the comparison phases as well as the user interface itself, contributing new filters, new grouping options, changing the displayed labels for the differences, or changing the displayed items altogether.

Quality of APIs

The component lead certifies that the requirements for Eclipse Quality APIs have been met for this release. All non-API code is in "internal" packages.

End of Life Issues

Though 3.0 is a major release, there are very few breakages as compared to last year's 2.1 version. The small number of API breaks are all localized in the UI code and not used as far as we know. The EMF Compare team will swiftly answer inquiries regarding these breakages on the official communication channels.

All mehods and classes that face deletion have been marked as deprecated with instructions on how to switch to the new behavior, and will stay in the code base until the next release.

Commiter Diversity

4 active commiters from Obeo

  • Cédric Brun
  • Laurent Goubet
  • Mikaël Barbero (Project Lead)
  • Axel Richard

1 inactive commiter from Itemis and 1 from Obeo

  • Cédric Notot
  • Patrick Könemann

IP Issues

The about files and use licenses are in place as per the Guidelines to Legal Documentation.

Large contributions have been made through individual CQs, which can all be consulted from .

All other contributions (code, documentation, images, etc) have been committed by individuals who are either Members of the Foundation or have signed the appropriate Committer Agreement. In either case, these are individuals who have signed, and are abiding by, the Eclipse IP Policy. The other contributions of the IP log are not significant or are written 100% by employees of the same employer (Obeo) as the Submitting Committer (

All contribution Questionnaires have been completed.

The "provider" field of each plugin is set to "Eclipse Modeling Project".

The "copyright" field of each plugin is set to the copyright owner.

Any third-party logos or trademarks included in the distribution (icons, logos, etc) have been licensed under the EPL.

The EMF Compare IP log is located at

Non-Code Aspects

Continuous Integration

Project is built from the EMF Compare HIPP through Tycho. A nightly is built once a day if the SCM polling sees a change from the last build.

Unit Tests

1103 unit tests launched on every build.

Code coverage is about 70% of the core.

Code Quality

Common formatter and compiler configuration used throughout the whole project's plug-ins.

Checkstyle activated on most distinct plug-ins.

Eclemma used on a regular basis to ensure and improve code coverage from the unit tests.

Yourkit java Profiler used on a regular basis to improved performances and avoid bottlenecks.

Findbugs launched on a regular basis to avoid detectable bugs.

Javadoc represents about 40% of the java source code.

An analysis of the code base is available on Ohloh.


Metamodel definitions and interfaces are considered APIs.

Commitment to provide stand-alone comparison feature (Jar that can be used without Eclipse with minimal to no dependencies towards eclipse core Jars).

Non-API classes are separated from the exposed API through an "internal" namespace.

Non-API packages are exported with an internal visibility so that they remain visible but with a discouraged access warning.


All of the documentation for EMF Compare is available online at [1]. It will be completed and extended with tutorials as the version matures.


Here is a snapshot taken on May the 16th of all bugs that have changed since release 2.0.0 (Juno). These figures are subject to change until the official release of 2.1.0 as the Team is currently in the process of fixing bugs.

EMF Compare 3.0 Bugzilla Snapshot.png

Note that these are only the bugs that changed somehow in-between the two releases (2.1 and 3.0), reflecting the activity during Luna development. At the time of writing, there are 59 opened and 2 unconfirmed bugs against EMF Compare.

Tool usability

Localization : integrated into Babel


No standard exists concerning the model comparison, though EMF Compare works nicely with any standard-based metamodel.

Since the 1.2 release a specific support for the UML standard is included in EMF Compare. This is also included in the 3.* stream.

UI Usability

EMF Compare is conforming to the Eclipse user interface guidelines.


Talks have been given on the following events:

Talks have been submitted for the following events: Eclipse Con France 2014:

Other medium:

  • Activity on the newsgroups
    • eclipse.modeling.emf : 60 new threads on EMF Compare from June 2013 to May 2014
    • : 13 new threads on EMF Compare from June 2013 to May 2014
  • About one update every two months on Planet Eclipse.

Committer Changes

There have been no changes in the list of commiters for this release, but the project lead has switched from Cédric Brun to Mikaël Barbero in November 2013 (


EMF Compare 3.0 follows the Kepler Release train, on +2 offsets.

Name Date
3.0.0M1 2013/08/23
3.0.0M2 2013/10/04
3.0.0M3 2013/11/15
3.0.0M4 2013/12/20
3.0.0M5 2014/01/31
3.0.0M6 2014/03/14
3.0.0M7 2014/05/29
3.0.0RC1 2014/05/23
3.0.0RC2 2014/05/30
3.0.0RC3 2014/06/06
3.0.0RC4 2014/06/13
3.0.0 2014/06/25

Project Plan

The EMF Compare 3.0 project plan is available at

Legal Notices

Java and all Java-based trademarks are trademarks of Oracle, Inc. in the United States, other countries, or both.

UML and XMI are trademarks of the Object Management Group.

Other company, product, or service names may be trademarks or service marks of others.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.