Skip to main content

EMF Diff/Merge (EDM)

EMF Diff/Merge (EDM)

The "EMF Diff/Merge" (EDM) project is a proposed open source project under the EMF Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment and/or join the project. Please send all feedback to the Eclipse Proposals Forum.


Comparing and merging models is a common need in modeling activities. A very frequent use case is version control: whenever team working is involved, models require similar versioning and merge facilities as source code. Even in collaborative environments such as CDO, the possibility for users to work offline implies a later synchronization, and therefore diff/merge, with the model repository. Besides, many classic features involve some kind of model merging: bridges between tools, model migration, model refactoring, incremental model transformation, etc.

However, merging models is more challenging than merging text or code. EMF-based models are rich data structures constrained by their metamodel, therefore a single change in an element may have consequences to other elements. If users are not assisted by their diff/merge tool, they may make contradictory or inconsistent merge decisions leading to data loss and incorrect, unexpected model content. This problem can become critical with large, complex models whose merging requires time-consuming efforts.


EDM provides a lightweight engine for comparing and merging models using IDs. The emphasis is on scalability and reliability, with the objective of preserving the integrity and consistency of models during the merge process. EDM is intended to be a technological enabler: it includes both a customizable diff/merge engine and Graphical User Interface (GUI) components which can be used by or integrated into other tools.


EDM supports 2-way and 3-way comparison of models that conform to EMF-based metamodels. Similarly to traditional file comparison, a 2-way comparison involves two models while a 3-way comparison involves an additional "common ancestor" model which enables the engine to identify the origin of differences.

The usage process is illustrated by the figure below. First, a comparison is created based on the models to compare. The differences between those models are computed according to given policies. Then, as long as differences remain, any subset of these differences can be selected for merging. Every time, EDM uses predefined consistency rules and a user-defined consistency policy to compute the minimal superset of differences that must be merged to preserve consistency. The user may decide whether to confirm or cancel the merge of the whole set of differences.

EDM primarily matches model elements by IDs, where an ID can be any criterion that uniquely identifies the element within the scope of the comparison: Ecore ID, qualified name, etc.

The EDM engine operates at a technical level: it is based on a notion of low-level difference which is suitable to consistent merging. EDM is thus not intended to provide high-level "semantic" feedback to the user. However, higher-level comparison frameworks could use the EDM engine as a back-end for enforcing consistent merging while relying on their own high-level difference model.

The EDM engine is expected to provide at least the following features:

  • Support for different scopes. The models being compared can be obtained from one or several files, a repository, a given set of model elements, etc.
  • Extensibility/adaptability. Customization of the match, diff and merge phases thanks to user-defined policies and comparison scopes.
  • Conflict detection. The notion of conflict in 3-way model comparison is significantly different from its counterpart in text comparison. If users A and B rename the same model element E differently, then it is obviously a conflict. However, if user A renames E and user B deletes E, then these two changes can also be considered in conflict because accepting one of them implies to reject or nullify the other one. The engine must be able to detect such cases.

The GUI is directly based on the concepts of the engine and hence reflects their technical nature. It may not be best for users willing to have a high-level overview of differences; however, it is helpful for experimenting comparison policies, or handle complex models that require a good understanding of the merging process. Additionally, the GUI is able to provide advanced feedback based on the features of the engine.

The GUI is expected to provide at least the following features:

  • Overview of merge impact. Whenever the user selects differences to merge, all consistency-dependent differences must be presented to him/her. The objective is that the user clearly understands the global impact of his/her actions on the model.
  • Conflict notification. Whenever the user attempts to merge differences that conflict with others, the GUI must highlight the cause of the conflicts and ask for confirmation.
  • Undo/redo of merge actions. Whenever the user makes wrong merge actions, (s)he must be able to undo them without any harm to the models.

Why Eclipse?

Since the main purpose of EDM is to integrate into higher-level tools, the interest of the community is critical to its success. The Eclipse ecosystem is the central place where projects that could benefit from EDM are available.

Initial Contribution

  • The initial engine solely depends on Eclipse runtime and EMF. It has been successfully used for version control in several real-life projects. It has also been embedded in a CASE tool as an enabler for model refactoring and incremental model transformations, which allowed to check that it can effectively be reused and integrated.
  • The initial GUI is based on SWT/JFace, Eclipse UI and Eclipse Compare. It supports visual comparison of models within Eclipse with integrability in mind. Its overall design was worked out in collaboration with users from industry. Although not as mature as the engine, it has been successfully tested on models of industrial size.

Legal Issues

The whole content of the initial contribution is currently property of Thales/TGS.

Relationship with Other Eclipse Projects/Components

  • EMF: EMF provides the foundations of the whole Eclipse modeling ecosystem. Since EMF defines what a model and a metamodel are, EDM is closely coupled to EMF.
  • EMF Compare: Altough EMF Compare and EDM both provide comparison and merge facilities, they are essentially complementary. EMF Compare is focused on being an end-user tool; as such, it provides integration mechanisms with components like GMF, eGit, EcoreTools, Papyrus. It also provides ways to specialize its difference model in order to obtain a semantic, user-friendly rendering of the changes. For example, a specialization exists for UML and SysML. By contrast, EDM operates at a lower level of abstraction: its difference model is technical so as to support the expression of consistency rules. Consequently, EMF Compare could rely on the EDM engine whenever a particular consistency policy must be enforced.
  • Eclipse Compare: Eclipse Compare provides hooks for contributing diff/merge tools to the Eclipse platform. The EDM GUI relies on Eclipse Compare.
  • Eclipse Team: Eclipse Team allows interacting with Software Configuration Management systems (SCMs) such as SVN or Git within Eclipse. Tools that rely on Eclipse Team for supporting version control of models may use EDM whenever merging is needed.
  • CDO and EMF Store: Model repositories such as CDO or EMF Store support collaborative modeling. They propose an offline mode which requires version branching and merge: EDM is typically intended to be useful in this context.
  • Others: Every EMF-related project which is concerned with model merging involving consistency policies.


Initial committers

The following individuals are proposed as initial committers to the project:

  • Olivier Constant, Thales/TGS, proposed project lead
  • Thomas Guiu, Soyatec
  • Matthieu Helleboid, Soyatec
  • Maximilian Kögel, EclipseSource
  • Eike Stepper, ES Consulting


The following Architecture Council members will mentor this project:

  • Cédric Brun
  • Ed Merks

Interested Parties

The following organizations have expressed interest in the project :

Developer and user communities

Critical to the success of this project is participation of interested third parties to the community. We intend to reach out to this community and enlist the support of those interested in making a success of the EDM project. We ask interested parties to contact EMF Forum to express interest in contributing to the project.

Tentative Plan

Initial contribution is expected during summer 2012.

Back to the top