Skip to main content
Jump to: navigation, search

EMF Compare/Release Review/2.1.0

< EMF Compare
Revision as of 11:31, 14 May 2013 by (Talk | contribs) (Commiter Diversity)

Kepler Release Review - EMF Compare 2.1

Laurent Goubet (

Release Review : May xx, 2013

Communication Channel : eclipse.modeling.emf newsgroup

Process Documentation :

Project Plan :

Release Highlights

EMF Compare 2.0 was a full overhaul of the design, architecture and code of the project. EMF Compare 2.1 comes to fill the functionality gap between 1.3 and 2.0, especially regarding content matching and graphical comparisons.

New and noteworthy

Content Matching

EMF Compare 2.0 only supported models that presented IDs of some sort : XMI ID, functional ID... 2.1 re-introduces support for other models through a content matching strategy.

By default, EMF Compare will try and match objects through their ID, delegating to the content matcher if none can be found. This can be altered to avoid using identifiers entirely when needed.

Graphical comparison

EMF Compare 1.3 provided basic support for GMF diagram comparisons and difference visualization. This basic implementation was dropped altogether in the 2.0 release as the architecture overhaul made it obsolete.

2.1 re-introduces the graphical comparison with a much more complete support on all aspects : comparison, visualization, merging... Here are a few key points of these enhancements.


Conflict detection

The conflict detection has been largely revamped in order to properly detect complex conflicts and pseudo conflicts (identical changes on both sides of the comparison are conflicting, but can be auto-merged... and as such are detected as "pseudo" conflicts). This also allows for much better results with extensions such as the UML or GMF specific supports.

Enhanced UI

The comparison UI has been enhanced to provide a much more precise and intelligible information. Among these improvements, the most notable are :

a comprehensive set of grouping options
a number of new difference filters
more complete contextual information around the differences
background comparisons
All comparisons launched from the UI are now executed as background operations. This will avoid the usual "frozen" Eclipse for long-running comparisons.
Direct edit
Textual differences can now be directly edited in the comparison editor for users that would rather use a mix of the left and right values instead of taking one or the other.

Customizable UI

One of the main limitations of the 1.* stream was its "locked" UI. EMF Compare 2.1 introduces a lot of customization options for the visualization of the differences and model elements.

  • Users can introduce new filters through the extension point. Filters can be contributed to either hide or show differences given a predicate.
  • New grouping options can be contributed through the extension point. The groups can be used to group differences together in the "structure" (top half) panel of the comparison UI.
  • Label providers can be contributed to override or extend the behavior of the default EMF label providers through the extension point. This can be used to change the way elements are displayed in the compare UI, both in the structure (top half) or content (bottom half) panels of the comparison UI.

Minimized Scope

EMF Compare 2.0 introduced the mandatory architecture and API for the project to handle large input models... Yet only provided a default scope which loaded everything in memory and compared the input models as a whole. 2.1 builds upon these APIs to introduce a scoping mechanism capable of treating model fragments as first-class citizens, minimizing the input logical model to the bare minimal while never loading the whole model in-memory unless all of its fragments have changed.

For example, assuming that we need to compare the three following models :

EMFC Logic origin.png
Left Right
EMFC Logic left.png
EMFC Logic right.png

Each of the three sides is an EMF model composed of 7 fragments. Origin is the common ancestor of left and right. The blue-colored fragments are those that actually present differences (so D and G have been modified in the "left" copy while only B has been modified in the "right" copy).

In order to compare these three models together, we would normally need to load all 21 fragments in memory. However, with the help of the synchronization model we can narrow it down to the modified fragments only. What we'll really load, then, are the following fragments for each three sides :

EMFC Logic loaded fragments.png

In other words, we are actually only loading 9 fragments out of the initial 21. This amounts to 58% less memory usage if we consider all fragments to be of equal "weight". And this is only for small models; the ratio of saved memory really going up for extremely large models. Of course, all of these objects that we are not loading in memory are all objects that we no longer need to compare, bringing an incredible performance boost along with the memory gain.


A number of new APIs have been opened in order to facilitate the programmatic use of EMF Compare and consumption of its output comparison model.

Pretty Printer

The comparison model contains a lot of information, which might be hard to consume or read. 2.1 introduces APIs that will provide more user-friendly descriptions for both differences and matched elements.

For example, here are the results for a given difference :

ReferenceChangeSpec{reference=EClass.eSuperTypes, value=EClass@3190dc79 TitledItem, parentMatch=MatchSpec{left=EClass@72b398da Book, right=EClass@675926d1 Book, origin=EClass@28d4ff95 Book, #differences=3, #submatches=5}, match of value=MatchSpec{left=<null>, right=EClass@3190dc79 TitledItem, origin=<null>, #differences=1, #submatches=1}, kind=ADD, source=RIGHT, state=UNRESOLVED}
EMFComparePrettyPrinter.printDifference(diff, System.out)
value TitledItem has been remotely added to reference eSuperTypes of object Book

Comparison Configuration

Most aspects of the comparison process can be customized before launching the comparison itself. All customizations can be made in a similar way through the EMFCompare class, they will be described in depth on the Developper guide.

For example, replacing the Match engine would be done through

IMatchEngine customMatchEngine = new MyMatchEngine(...);

Or replacing the Diff engine could be done with

IDiffEngine customDiffEngine = new MyDiffEngine(...);

Separation of the RCP, IDE and core concepts

EMF Compare 2.1 further enhances the separation of concerns that 2.0 introduced so that the core of the comparison process is all located in a single, fully standalone plugin that does not depend on Eclipse in the least.

Furthermore, all code that does not depend on the IDE has been extracted in "rcp" namespaces, both RCP and RCP UI are in this case, separated themselves in their own isolated plugins.

Mergers extensibility

The mergers have been greatly enhanced since the 1.* stream of EMF Compare, though 2.0 did not allow for easy overriding, replacing or inheriting of the default mergers.

EMF Compare 2.1 solves these concerns by introducing a more flexible merging mechanism, supporting any kind of combination of existing/new/overridden mergers along with a "batch" merging mechanism. Clients can refer to IMerger.Registry for more information on extending the default behavior.

Performance Enhancements

EMF Compare 2.1 introduced a minimized scoping mechanism, which will greatly enhance both the memory footprint and comparison time of all comparisons targetting fragmented models.

Furthermore, both aspects (memory footprint and overall time) have been fully profiled and enhanced for large model comparisons, this makes for a noticeable improvement on all comparisons, whether the input models are fragmented or not.

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

EMF Compare 2.0 being a full overhaul of the project, its API is not compatible with its previous 1.* versions. A migration guide will be provided in order to ease the adoption effort to this new version.

All API that was provided by the 1.* stream has been deprecated with the 1.3 release (see the 1.3 End Of Life Issues) and is no longer available in its previously existing state.

The extension points proposed by the 1.3 release have not been ported yet to the 2.* stream, but should be pressent in the subsequent 2.1 release.

The commiter for the MPatch plugins is now inactive, and this feature is thus no longer supported. There are no plans for the moment to port these plugins to the new core of EMF Compare.

Commiter Diversity

5 active commiters from Obeo

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

1 inactive commiter from Itemis

  • Patrick könemann

IP Issues

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

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 Eclipse hudson instance through Tycho. A nightly is built once a day if the SCM polling sees a change from the last build.

Unit Tests

349 unit tests launched on every build.

Code coverage is about 80% of the core.

Code Quality

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

Checkstyle activated on each distinct plug-in.

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 50% of the java source code.

An analysis of the code base page 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.


Documentation is not up-to-date yet.


No Bugzilla closed specifically for this release, however, all bugs closed for 1.3.0 had their fix up-ported to 2.0 so that no regression would be observed on the up-ported features and functionalities. See the Bugzilla snapshot for the 1.3 release.

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 2.0 release.

However, the 1.3 release saw the inclusion of a specific support for the SYSML standard comparison. This has not been up-ported to 2.0 yet.

UI Usability

EMF Compare is conforming to the Eclipse user interface guidelines.


Talks have been given on the following events: Eclipse Con Europe 2011 :

  • What every Eclipse Developer should know about EMF
  • What the heck are logical models?
  • EMFCompare improvements: fulfilling requirements of the Modeling Platform Working Group

Talks have been submitted for the following events: Eclipse Con Europe 2012:

Other medium:

  • Activity on the EMF newsgroup (eclipse.modeling.emf): 29 new threads on EMF Compare from June 2011 to May 2012
  • About one update every two months on Planet Eclipse.

Committer Changes



EMF Compare 2.0 Release Plan

M6	03/21/2012
M7	05/04/2012
RC1	08/03/2012
RC2	08/10/2012
Final	08/15/2012

Project Plan

The EMF Compare 2.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, SYSML, OMG, EMOF, OCL and XMI are trademarks of the Object Management Group.

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

Back to the top