Difference between revisions of "EMF Compare/FAQ/1.3"
(→Which files should be compared via EMF Compare ?)
|Line 1:||Line 1:|
Revision as of 03:03, 9 July 2013
Take good note that this FAQ is only aimed at EMF Compare 1.3, and that none of these answers is correct for EMF Compare 2.* users. Please refer to the updated FAQ for any question related to the 2.1 version.
- 1 Users
- 2 Developers
- 2.1 How can I programmatically add my model file extension in EMF Compare so that it is called automatically ?
- 2.2 Is EMF Compare, as EMF, able to run outside of Eclipse ?
- 2.3 How can I use EMF Compare programmatically?
- 2.4 What kind of "strategies" use EMF compare ?
- 2.5 What evolution should we expect on the global EMF compare strategies ?
- 2.6 Custom data types are always marked as modified by EMF Compare
Which files should be compared via EMF Compare ?
Q : My model is compared as a text-file, how can EMF compare know the files it should handle ?
A : EMF compare uses a content-type to know whether it should be used for comparison. This content-type will initially register itself against *.ecore and *.uml files. You may add your own extension using the Preferences view / General / Content-types and adding your file extension in the "EMF Compare" content-type.
How to force text comparison?
Q : uml, ecore and emfdiff models are "locked" as model files in the aforementioned "EMF Compare" content-type. I want to compare two uml files as text, is there a way to do so?
A : You can force text comparison of those "locked" model files by adding their extension to the "text" content type in the same way as what is explained above.
EMF Compare compatibility?
Q : Which Java/Eclipse versions can EMF Compare run on?
A : EMF Compare is built against JDK 1.5 and makes use of the features it introduced such as foreach and generics. It is therefore incompatible with a JDK < 1.5. We've also used EMF Compare successfully with both JDK 1.6 and JDK 1.7 early builds. As for Eclipse; as mentionned above, EMF Compare makes intensive use of JDK 1.5 features. These have been introduced with EMF 2.3 which isn't compatible with Eclipse < 3.3, EMF Compare is therefore only compatible with Eclipse 3.3 and higher.
How can I programmatically add my model file extension in EMF Compare so that it is called automatically ?
Q : How can I programatically add my model file extension in EMF Compare so that it is called automatically ?
A : Using the "EMF Compare" content-type defined with EMF Compare, here is a sample from a plugin.xml:
<extension point="org.eclipse.core.contenttype.contentTypes"> <file-association content-type="org.eclipse.emf.compare.ui.contenttype.ModelContentType" file-extensions="uml13" file-names="*"/> </extension>
Is EMF Compare, as EMF, able to run outside of Eclipse ?
Q : Is EMF Compare able to compare "in-memory" objects, and can it be run without Eclipse ?
A: Yes, an example Java project doing just that is accessible on CVS here. See README file of this example in order to get it to run
How can I use EMF Compare programmatically?
Q : How can I use EMF Compare programmatically? Is there any example for such use cases?
A : The example project mentionned above ([org.eclipse.emf.compare.examples.standalone]) should prove useful as an example for this issue. The following code snippet allows for loading, matching, differencing, then merging two models.
// Loading models EObject model1 = ModelUtils.load(model1, resourceSet); EObject model2 = ModelUtils.load(model2, resourceSet); // Matching model elements MatchModel match = MatchService.doMatch(model1, model2, Collections.<String, Object> emptyMap()); // Computing differences DiffModel diff = DiffService.doDiff(match, false); // Merges all differences from model1 to model2 List<DiffElement> differences = new ArrayList<DiffElement>(diff.getOwnedElements()); MergeService.merge(differences, true);
What kind of "strategies" use EMF compare ?
Q : What kind of "strategies" use EMF compare ? On which research work is it based ?
A : The emf compare generic engine is based on several research work and on experimentations. The paper being the most "near" the emf compare behavior is probably "UMLDiff: An Algorithm for Object-OrientedDesign Differencing" by Zhenchang Xing and Eleni Stroulia. Other reseach work have been used and a lot of them use the same kind of general behavior: A comparison in 2 phases, the first being the matching phase and the second the differencing phase. The matching is done computing comparison metrics and getting an "overall" rank of matching for two nodes while browsing both versions of the model. These metrics may change considering the research work, here in the generic engine we use 4 metrics :
- type similarity : analysing the metamodel element
- name similarity : looking for an attribute which have chances to be the name and comparing it
- value similarity : analysing the whole attributes values
- relations similarity : using the relations the element has with others.
Using these 4 metrics the comparison engine provide good correctness (most especially comparing models from DSM/DSL's metamodels) and efficiency when comparing big models (~=100 000 elements).
Once the matching phase is done, the matching model is browsed by the differencing engine computing "added", "deleted" or updated elements from that. If you save a comparison as an emfdiff model you'll be able to browse the match and diff model and you'll get the similarity ranking for each couple of elements.
You can find more information in the article: Model Differences in the Eclipse Modelling Framework by Cédric Brun and Alfonso Pierantoniofo in the 2008 Issue 2 Cepis Upgrade Journal: http://www.cepis.org/upgrade/index.jsp?p=0&n=2148&a=3058
We're open to suggestion to enhance this generic behavior but we are also open to other methods : we want this component to be a testbed for other algorithms and comparison techniques, any Eclipse plugin may contribute its own matching and differencing engine for generic or specific purpose and it would be quite interesting to compare the results from different engines on different models.
These strategies will probably evolve in the next releases (see following question).
What evolution should we expect on the global EMF compare strategies ?
Q : What evolution should we expect on the global EMF compare strategies ?
A : We are trying to get better results with generic comparison algorithm through other methods coming from the research world. An initiative about model transformation/weaving and comparison is taking place in Europe an you may expect that the EMF compare implementation will evolve toward these works.
Custom data types are always marked as modified by EMF Compare
Q : A model based on a custom meta-model always shows elements of a custom data type as being changed. How can I have EMF Compare behave correctly?
A : EMF Compare's differencing process is based on the return value of equals() and will then fail to determine if two objects are equals if the equals() method hasn't been overriden in the custom data type's instance class. Remember to also override hashCode() when overriding equals().
See bug #226152 for an example of such problems.