EMF Compare/New and Noteworthy/2.0.0

Architecture Overhaul

EMF Compare 1.* presents limitations that cannot be worked around in order to fix some of the problems identified with the project : merging, scoping, memory performance... Furthermore, this version of EMF Compare proposed a somewhat complex API to its clients and we cannot easily re-design this to ease the project's use.

One of the main goals of EMF Compare 2 is to do a complete overhaul of the project's architecture in order to lift these limitations and clarify the API we provide to our adopters. Among other changes, the core model of EMF Compare will be simplified for clarity, and the main interfaces to launch comparisons and merges of two or three models will be made less convoluted.

Perfect Merge

EMF Compare 1.x was missing some information during the differencing which led to merges being, in some case, unreliables. EMF Compare 2.x is fixing this by keeping more information about the differences, computing the requirement graph of differences and computing equivalence relationships between differences (this may arise for instance, if you have eOpposite references).

The ultimate goal being a 100% reliable merge.

Support for Large models

Though this was also one of the priorities of the 1.3 release that shipped along with the Juno release train, this is one of the points for which we had to make compromises in order to cope with the aforementioned limitations of the 1.* stream. EMF Compare 1.3.0 did propose a lot of improvements on the scalability front, but we could not ensure scalability for millions of elements as can be seen in most "real-life" models used by our adopters in production.

EMF Compare 2.0 will provide the mandatory architecture and API changes required for the project to handle such a scale of input models. Namely, it will propose a "scope" feature that will be fully customizable so that the subsequent version of EMF Compare, 2.1, can provide the fragmented scope that will be able to handle extremely large input models. In short, EMF Compare will be able to function with time and memory footprints dependent on the number of actual differences instead of being dependent on the input models' size.

ID based matching or Content/Structure based matching

Just like EMF Compare 1.x, The 2.0.0 release is able to compare models using their IDs to match elements, or not using them and matching elements using their content.

The content/structure based matching has been re-implemented and is provides now the guarantee to always pick the closest match for a given EObject, even it the closest match has been moved a long way in the model.

Keep in mind matching graphs is an NP problem (as in highly complex and computation intensive) and EMF compare rely a lot on the fact that most objects won't change from version to version. 

Scoped Model Comparison and No proxy resolution

The API now enable you to clearly define what you want to get compared. EMF Compare just takesIterator<EObject> as inputs and walk through them once, never resolving proxies itself.

Integration with the Eclipse UI

EMF Compare 1 presented a user interface mimicking the standard Eclipse compare UI, but which was not really integrated with it : folder comparison was not using EMF Compare to show structural differences, the viewers were our own, the displayed elements weren't compatible with what Eclipse Compare was expecting...

EMF Compare 2 is now deeply integrated with Eclipse Compare, reusing its API in each and every possible means. This means that the icons will be the exact same as the standard "text" comparisons, the behavior will be closer to Eclipse compare (notably on folder comparisons and viewer switching)...

Standalone Jar

EMF Compare 1.x can be used as a standalone jar, but in fact you would need a bunch of jars. With the 2.x stream you can match, diff an d merge models just by using org.eclipse.emf.compare.jar

Performance Enhancements

Some performance bottlenecks in EMF Compare 1.3 have been identified yet cannot be solved without fully re-thinking the comparison process. EMF Compare 2.0 will provide these enhancements and will be faster than the 1.* stream even without the aforementioned changes that are planned for version 2.1.

Tycho based build

Building your own fork of EMF Compare is now one command away from you :

mvn clean verify 

from the org.eclipse.emf.compare-parent directory.

You can even check the build still works for several platforms

mvn clean verify -Pindigo

or

mvn clean verify -Pjuno

A few missing parts

Diagram and UML Comparison have been removed for this release and will come back with the 2.1 release.