Skip to main content
Jump to: navigation, search

Difference between revisions of "EMF Compare/Roadmap"

(Long Term)
Line 5: Line 5:
  
 
=== Framework Enhancements ===
 
=== Framework Enhancements ===
==== per namespace MatchEngine selection and dynamic switching ===
+
==== 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  
 
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.
 
broadly used we often encounter cases where a given file contains model elements conformed to several Ecore models.
Line 13: Line 13:
  
  
=== 2 ways and 3 ways merge robustness ====
+
==== 2 ways and 3 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 ...
 
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 ===
+
==== 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).
 
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 ===
+
==== 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.
 
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.
 
We should build a strong test basis with eObjects not being in resources, being compared and merged.
  
* MatchModel maintenance on incremental changes
+
==== 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
+
==== DiffModel maintenance on incremental changes ====
* Re-Usable Comparison UI Component
+
* Undo/Redo support in comparison editor
+
* ChangeModel to DiffModel and DiffModel to ChangeModel
+
  
=== Tooling Enhancements ===
+
Once the match model is maintained incrementaly, the next step is to maintain the diff model accordingly.
* Integration with the Team Model Synchronization UI
+
* Generating a Custom Match Engine from Ecore Annotations.
+
  
 +
==== 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 ====
 +
 +
==== ChangeModel to DiffModel and DiffModel to ChangeModel ====
 +
 +
=== Tooling Enhancements ===
 +
==== Integration with the Team Model Synchronization UI ====
 +
==== Generating a Custom Match Engine from Ecore Annotations ====
  
 
== 2011 ==
 
== 2011 ==

Revision as of 10:46, 27 August 2010

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.


2 ways and 3 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

ChangeModel to DiffModel and DiffModel to ChangeModel

Tooling Enhancements

Integration with the Team Model Synchronization UI

Generating a Custom Match Engine from Ecore Annotations

2011

2012

2013

Released bits

2010

2009

2008

Back to the top