Eclipse Community Forums: Compare » Configuring EMF Compare

Help

Home

Home » Modeling » Compare » Configuring EMF Compare

Show: Today's Messages :: Show Polls :: Message Navigator

Configuring EMF Compare [message #1015642]

Fri, 01 March 2013 14:03

Tim Geisler

Messages: 47
Registered: July 2009

Member

Hi,

I'd like to use EMF Compare to compare artifacts of a DSL implemented using Xtext.

When I register the file extension of my DSL as appropriate content type, as described in the FAQ:

<extension
    point="org.eclipse.core.contenttype.contentTypes">
  <file-association
      content-type="org.eclipse.emf.ecore.xmi"
      file-extensions="uml"
      file-names="*"/>
</extension>

EMF Compare is called. Perfect.

But, in order to only display the desired comparison results and to be more efficient, I need to use my own match engine.

There are some extension points for EMF Compare (in org.eclipse.emf.compare.extension), but they seem to not allow to specify the match engine, but only post-processing steps.

How do I register my own match engine (and/or any other customization code for EMF Compare) in this case? Perhaps I am just spoiled by the ease of configuring nearly everything in Xtext ...

I use EMF Compare 2.

Best regards,

Tim

Report message to a moderator

Re: Configuring EMF Compare [message #1015654 is a reply to message #1015642]

Fri, 01 March 2013 14:35

Laurent Goubet

Messages: 1895
Registered: July 2009

Senior Member

Tim,

Not everything is documented yet (far from it :s), but some of the extension capabilities are, a good place to start is thus the wiki.

Replacing the whole Match engine is not possible yet, we could do every modification needed for UML and GMF integration as post-processing steps. Are you sure you cannot? Note that post-processors are available for each comparison step, so you can define one to refine the Match result before the Diff engine kicks in (the Diff engine only uses the result of the Match as input, it does not look at the input models of the comparison).

The only API that's opened (for now) to replace the match engine used by EMF Compare when called from the UI (as opposed to programmatic calls) is the post-processor. More extension points are planned, but that'll only be for M7 at best (M7 is due the 7th of May). If you have specific needs on that point, please share them Smile

.

If you have specific questions on how to handle your own use case, do not hesitate to ask.

Laurent Goubet
Obeo

Report message to a moderator

Re: Configuring EMF Compare [message #1015667 is a reply to message #1015654]

Fri, 01 March 2013 15:32

Tim Geisler

Messages: 47
Registered: July 2009

Member

Hi Laurent,

thanks for you quick answer.

I know the documentation of the extension capabilities for programmatically calling EMF Compare (we already use them indeed).

The issue is that calling EMF Compare 2.1 for medium sized models (15k lines of code in the DSL) takes very long time (longer than a long coffee break and to write this reply) and Eclipse freezes during that time. The time is spent inside DefaultMatchEngine.match(...) in code which determines whether two objects match. For my DSL, the model structure is really simple. There might be a large set of elements of different type where a match or non match could be determined by just comparing their EClass and value of "name" attribute.

With this matching performance, EMF Compare is quite unusable.

So, my way out until May (I cannot wait so long since a potential customer is interested in comparing models) is to use the way of programmatically configuring EMF Compare and to add suitable comparison actions in parallel to the actions which already exist in Eclipse?

Best regards,

Tim

Report message to a moderator

Re: Configuring EMF Compare [message #1016301 is a reply to message #1015667]

Tue, 05 March 2013 22:50

Tim Geisler

Messages: 47
Registered: July 2009

Member

The way to improve matching performance and quality for my DSL is to
* set filters for the scope which filter out certain objects
* define an ID calculation
This has to be set in (a copy/subclass of) EMFCompareStructureMergeViewer. I do not see any way to do this in a post processor which runs after the match phase because this adaptions influence the match phase.

Now it remains to improve the UI. E.g., when comparing matching objects it would be nice to have them displayed as snippets in the textual DSL and not as XMI.

Best regards,

Tim

Report message to a moderator

Re: Configuring EMF Compare [message #1016361 is a reply to message #1016301]

Wed, 06 March 2013 08:42

Laurent Goubet

Messages: 1895
Registered: July 2009

Senior Member

Tim,

The latest builds provide a fair enhancement of the performance we get from the proximity matching engine, you might want to try that too (M6 is due the 22nd of March, you can try the very latest (nightly) build from there if you wish to give it a try (this is a p2 update site, you can use it to install the nightly directly).

Apart from that, the extension point that will allow users to provide their own match engine is planned for M7 (due the 7th of May).

If you cannot wait till May and the enhancements provided by M6 are not enough to make your use case acceptable, then yes, your only option is to provide your own EMFCompareStructureMergeViewer.

Laurent Goubet
Obeo

Report message to a moderator