Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EMF Compare/Specifications/Metamodel restructuration"
(→Introduction) |
|||
| Line 5: | Line 5: | ||
== Preamble == | == Preamble == | ||
| − | This specification aims at setting down on paper and clarifying the requirements for the restructuration of both match and diff metamodels. | + | This specification aims at setting down on paper and clarifying the requirements and needs for the restructuration of both match and diff metamodels. |
_Relevant tickets_ : | _Relevant tickets_ : | ||
| Line 20: | Line 20: | ||
== Detailed Specification == | == Detailed Specification == | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Backward Compatibility and Migration Paths == | == Backward Compatibility and Migration Paths == | ||
| − | |||
| − | |||
=== Metamodel Changes === | === Metamodel Changes === | ||
Revision as of 11:59, 1 February 2012
Evolution Specification: Title of the evolution
Current status is PROPOSAL
Preamble
This specification aims at setting down on paper and clarifying the requirements and needs for the restructuration of both match and diff metamodels.
_Relevant tickets_ :
Introduction
The development of EMF Compare has been ongoing for quite some time, and we have reached the limits of what can be expressed with the current definition of our metamodels. First is the "match" metamodel, serving the purpose of expressing the result of EMF Compare's matching phase. It allows us to map the objects from two distinct models two-by-two, and to "mark" the objects with no match (present in one model but not in the other). Second is the "diff" metamodel, which allows us to express the differences themselves. Both of these models must be refactored in order to fix some of the current implementation bugs.
For example, the match model does not allow us to express that an "unmatched" element may contain a "matched" one : if an existing element A (matched) has been moved to a newly added (thus unmatched) element B. As for the diff model, it has become hard to read over time as we tried to maintain existing APIs while adding fundamentaly new concepts (the diff model has not changed much when we introduced three-way matching).
The goal of these restructuration are both :
- to increase the readability and ease the understanding of the metamodel concepts,
- to allow us to express what cannot be done with the current versions.
Detailed Specification
Backward Compatibility and Migration Paths
Metamodel Changes
Document any change to the Viewpoint metamodel. If they require a migration operation, mention it and describe the general idea of how migration process. If any information can be lost during the migration, mention it clearly. If validation rules must be added/modified, mention it also.
API Changes
List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.
User Interface Changes
List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.
Documentation Changes
List every documentation needing an update here, starting by the New and Noteworthy documentation.
Tests and Non-regression strategy
This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.
Implementation choices and tradeoffs
Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.