Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EMF Compare/Roadmap"
(→2011) |
(→2011) |
||
| Line 76: | Line 76: | ||
* [[EMF Compare 1.2.0 New And Noteworthy | New and Noteworthy : 1.2.0]] | * [[EMF Compare 1.2.0 New And Noteworthy | New and Noteworthy : 1.2.0]] | ||
| − | + | * [[EMF Compare/CompareUMLPapyrusAPI | EMF Compare enhancements (tree editor, API, UML, Papyrus)]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
== 2012 == | == 2012 == | ||
Revision as of 04:45, 21 February 2011
Contents
- 1 Plan
- 1.1 Long Term
- 1.1.1 Framework Enhancements
- 1.1.1.1 per namespace MatchEngine selection and dynamic switching
- 1.1.1.2 Two ways and Three ways merge robustness =
- 1.1.1.3 High Performances during matching phase
- 1.1.1.4 Match/Diff/Merge on elements not contained in a EMF Resource
- 1.1.1.5 MatchModel maintenance on incremental changes
- 1.1.1.6 DiffModel maintenance on incremental changes
- 1.1.1.7 Re-Usable Comparison UI Component
- 1.1.1.8 Undo/Redo support in comparison editor
- 1.1.1.9 ChangeModel to DiffModel and DiffModel to ChangeModel
- 1.1.2 Tooling Enhancements
- 1.1.1 Framework Enhancements
- 1.2 2011
- 1.3 2012
- 1.4 2013
- 1.1 Long Term
- 2 Released bits
Plan
Long Term
EMF Compare's focus is on providing a powerful, stable and proven framework for model comparison and merging. The API should be usable in any context from the plain Java application to the complete IDE customization.
Framework Enhancements
per namespace MatchEngine selection and dynamic switching
Right now EMF compare allows adopters to define specific match or diff engines associated with file extensions. As EMF is more and more broadly used we often encounter cases where a given file contains model elements conformed to several Ecore models.
A MatchEngine (and respectively Diff Engine) should be associated with one or several EPackages and not with the serialization mechanism. Furthermore that would require the Match process in general to be able to switch from a MatchEngine to another depending on the elements it is matching.
Two ways and Three ways merge robustness =
We have a bunch of issues reported by the adopters about the merge support, we need to work on building a strong test basis to make sure the merge is perfect in any kind of scenarios for instance fragmented models, scoped matching ...
High Performances during matching phase
The matching phase is critical for performances, several optimization could be done (some being addressed by the Google Summer of Code 2010).
Match/Diff/Merge on elements not contained in a EMF Resource
The framework can be used on any kind of EObjects, but as historically it was about providing model comparison support for file based models many parts of the code are making assumptions about a resource being there or not.
We should build a strong test basis with eObjects not being in resources, being compared and merged.
MatchModel maintenance on incremental changes
Right now the match process is not split in several parts, and as such when one of the matched models has been changed all the resource set needs to be matched again. We should be able to maintain parts of the match model and update those when the matched models have been changed.
DiffModel maintenance on incremental changes
Once the match model is maintained incrementaly, the next step is to maintain the diff model accordingly.
Re-Usable Comparison UI Component
Several adopters expressed their will to reuse parts of the compare UI. Right now it's nor really doable as the UI is pretty tied to the Eclipse compare framework.
This task is about defining a new API one can easily reuse splitting content provider and viewers just like JFace.
Undo/Redo support in comparison editor
This involve having a proper editing domain and using commands for merging. It can quickly become tricky as our editing domain would need to operate on 2 resourcesets keeping them separated.
ChangeModel to DiffModel and DiffModel to ChangeModel
The ChangeModel is a model defined in EMF representing changes. It semantically overlap a bit with the DiffModel from EMF compare. It would be interesting to at least bridge these models or even try to replace our DiffModel by the EMF ChangeModel if possible.
Tooling Enhancements
CodeGen
When you starts your own Ecore model you quickly want to :
- compare instances in an controlled and efficient way
- process these deltas
We'll work on integrating EMF Compare more with EMF providing you codegen facility to get, with a single click :
- an efficient dedicated match engine with areas providing you the ability to customize the process
- an efficient dedicated delta processor so that you can easily plug your own logic to process deltas
A user will be able to generate these artifacts directly from the genmodel with a right-click action. The generated code will be very similar to the XYZSwitch generated by EMF Core.
Integration with the Team Model Synchronization UI
The Eclipse Compare API provides what they call a "Comparison Model" which might be used in the synchronization view. It would allow to display the differences grouping them by dependencies even when several resources are involved.
Generating a Custom Match Engine from Ecore Annotations
The Generic Match Engine is pretty powerful though based on heuristics. When you defined your own Ecore model you often want's to make sure you control the way elements are being matched and not rely on statistics. Right now to do so you have to write your own match engine as Java code but this induce un-necessary overhead for many cases. We could define a small set of annotations at the Ecore level so that one can specify for instance :
- attributes to ignore during the match
- features which - if they are different - means the elements can't be matched.
the GenericMatchEngine would either adapt its behavior depending on these annotations, or we could provide a code generator generating the MatchEngine from the annotated Ecore model.
2011
2012
2013
Released bits
2010
2009
2008
- Initial project description : EMF Compare Description (PDF)