Skip to main content
Jump to: navigation, search

EMF Compare/Release Review/2.1.0

< EMF Compare
Revision as of 10:11, 14 May 2013 by (Talk | contribs) (New page: = Kepler Release Review - EMF Compare 2.1 = Laurent Goubet ''('' Release Review : May xx, 2013 ''Communication Channel : eclipse.modeling.emf newsgroup'' ''Proce...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.


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 PENDING a number of new difference filters PENDING more complete contextual information around the differences PENDING

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

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

4 active commiters from Obeo

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

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