|
Re: Configuring EMF Compare [message #1015654 is a reply to message #1015642] |
Fri, 01 March 2013 14:35 |
|
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 .
If you have specific questions on how to handle your own use case, do not hesitate to ask.
Laurent Goubet
Obeo
|
|
|
|
|
Re: Configuring EMF Compare [message #1016361 is a reply to message #1016301] |
Wed, 06 March 2013 08:42 |
|
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.03612 seconds