|
|
(22 intermediate revisions by the same user not shown) |
Line 1: |
Line 1: |
− | =Users=
| + | #REDIRECT[[EMF_Compare/FAQ]] |
− | ====My model is compared as a text-file, how can EMF compare know what file it should handle ?====
| + | |
− | '''Q''' : My model is compared as a text-file, how can EMF compare know what file it should handle ?
| + | |
− | | + | |
− | '''A''' : EMF compare uses a content-type to know if it should be started or not. By default this content-type is composed of *.ecore and *.uml file but you may add your own extension using the <tt>Preferences view / Global / Content-types</tt> and adding your file extension in the "Model File" content-type.
| + | |
− | | + | |
− | [[Image:EMFComparePreferences-content-type.png]] | + | |
− | | + | |
− | ====How to force text comparison?====
| + | |
− | '''Q''' : uml, ecore and emfdiff models are "locked" as model files in the aforementioned "Model File" 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.
| + | |
− | | + | |
− | ====Is EMF Compare compatible with the JDK 1.4?====
| + | |
− | '''Q''' : Will EMF Compare work with JDK 1.4?
| + | |
− | | + | |
− | '''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.
| + | |
− | | + | |
− | =Developpers=
| + | |
− | ====How can I programatically 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 "Model File" content-type defined with EMF Compare, here is a sample from a plugin.xml:
| + | |
− | <pre>
| + | |
− | <extension
| + | |
− | point="org.eclipse.core.contenttype.contentTypes">
| + | |
− | <file-association
| + | |
− | content-type="org.eclipse.emf.compare.ui.contenttype.ModelContentType"
| + | |
− | file-extensions="uml13"
| + | |
− | file-names="*"/>
| + | |
− | </extension>
| + | |
− | </pre>
| + | |
− | | + | |
− | ====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 Eclispe ?
| + | |
− | | + | |
− | '''A''': Yes, here is a snippet doing that:
| + | |
− | <pre>
| + | |
− | /**
| + | |
− | * This application will try and launch an headless model comparison.
| + | |
− | *
| + | |
− | * @author Cedric Brun <a href="mailto:cedric.brun@obeo.fr">cedric.brun@obeo.fr</a>
| + | |
− | */
| + | |
− | public final class ExampleLauncher {
| + | |
− | /**
| + | |
− | * This class doesn't need to be instantiated.
| + | |
− | */
| + | |
− | private ExampleLauncher() {
| + | |
− | // prevents instantiation
| + | |
− | }
| + | |
− | | + | |
− | /**
| + | |
− | * Launcher of this application.
| + | |
− | *
| + | |
− | * @param args
| + | |
− | * Arguments of the launch.
| + | |
− | */
| + | |
− | public static void main(String[] args) {
| + | |
− | if (args.length == 2 && new File(args[0]).canRead() && new File(args[1]).canRead()) {
| + | |
− | // Creates the resourceSet where we'll load the models
| + | |
− | final ResourceSet resourceSet = new ResourceSetImpl();
| + | |
− | try {
| + | |
− | // Loads the two models passed as arguments
| + | |
− | final EObject model1 = ModelUtils.load(new File(args[0]), resourceSet);
| + | |
− | final EObject model2 = ModelUtils.load(new File(args[1]), resourceSet);
| + | |
− |
| + | |
− | // Creates the match then the diff model for those two models
| + | |
− | final MatchModel match = new DifferencesServices().modelMatch(model1, model2, new NullProgressMonitor());
| + | |
− | final DiffModel diff = new DiffMaker().doDiff(match);
| + | |
− |
| + | |
− | // Prints the results
| + | |
− | try {
| + | |
− | System.out.println(ModelUtils.serialize(match));
| + | |
− | System.out.println(ModelUtils.serialize(diff));
| + | |
− | } catch (IOException e) {
| + | |
− | e.printStackTrace();
| + | |
− | }
| + | |
− |
| + | |
− | // System.out.println("saving diff as \"result.diff\"");
| + | |
− | // ModelUtils.save(diff, "result.diff");
| + | |
− | // System.out.println("saving match as \"result.match\"");
| + | |
− | // ModelUtils.save(match, "result.match");
| + | |
− |
| + | |
− | // Serializes the result as "result.emfdiff" in the directory this class has been called from.
| + | |
− | System.out.println("saving emfdiff as \"result.emfdiff\""); //$NON-NLS-1$
| + | |
− | final ModelInputSnapshot snapshot = DiffFactory.eINSTANCE.createModelInputSnapshot();
| + | |
− | snapshot.setDate(Calendar.getInstance().getTime());
| + | |
− | snapshot.setMatch(match);
| + | |
− | snapshot.setDiff(diff);
| + | |
− | ModelUtils.save(snapshot, "result.emfdiff"); //$NON-NLS-1$
| + | |
− | } catch (IOException e) {
| + | |
− | // shouldn't be thrown
| + | |
− | e.printStackTrace();
| + | |
− | } catch (InterruptedException e) {
| + | |
− | e.printStackTrace();
| + | |
− | }
| + | |
− | } else {
| + | |
− | System.out.println("usage : Launcher <Model1> <Model2>"); //$NON-NLS-1$
| + | |
− | }
| + | |
− | }
| + | |
− | }
| + | |
− | </pre>
| + | |
− | | + | |
− | ====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.
| + | |
− | | + | |
− | 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.
| + | |
− | | + | |
− | [http://www.model-transformation.org/ Model Transformation initiative]
| + | |