The project has been created.
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:
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:
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.
The whole content of the initial contribution is currently property of Thales/TGS.
The following individuals are proposed as initial committers to the project:
The following Architecture Council members will mentor this project:
The following organizations have expressed interest in the project :
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.
Initial contribution is expected during summer 2012.
Back to the top