| [Compare] Showing differences in a Comparison object? [message #988615] |
Fri, 30 November 2012 12:23  |
Eclipse User |
|
|
|
Hi all,
I'm one of the developers of the Epsilon project. We're running into some issues with EMF Compare 2.x while testing Epsilon against Kepler M3. We'd appreciate it if someone could help us a bit  .
We use EMF Compare as part of the EUnit unit testing framework bundled with Epsilon. It has some assertions that allow testers to check whether two models are equal ("assertEqualModels"). We rely on EMF Compare to compare EMF models and show their differences.
With EMF Compare 1.x, we used the standard services to create a ComparisonResourceSetSnapshot. If there were any differences, we showed them to the user by wrapping them in a ModelCompareEditorInput object and opening it through the CompareUI#openCompareEditor method. We had to tweak things a bit to handle some corner cases, but otherwise it was reasonably simple to do.
Since EMF Compare 2.x has changed things quite a bit, we've started rewriting the integration code. Comparing models seems even easier now than before: we produce a Comparison object and check if any differences have been reported. However, we're a bit stumped on how to convert that into a CompareEditorInput so we can pass it to CompareUI. ModelCompareEditorInput does not exist anymore, and we can't rely on the ResourceCompareInput class in the internal API of Eclipse Compare, as it requires using IResource objects. Due to technical constraints, the compared models may not be in the workspace.
Is there any way we can show the differences in the Comparison object? Do we need to use ResourceCompareInput and ensure compared models are in the workspace? Should we implement our own CompareEditorInput class?
Thanks in advance,
Antonio
|
|
|
|
|
| Re: [Compare] Showing differences in a Comparison object? [message #988831 is a reply to message #988796] |
Mon, 03 December 2012 06:28  |
| Eclipse User |
|
|
|
Hi Mikael,
Thanks! These changes were done after M3, right? Looking at the latest sources from git, EMFCompareEditorInput is very close to what we need. There's a few isues, though:
- The constructor takes a few arguments that are only used to perform a comparison in the prepareInput method. There seems to be a FIXME related to that in the prepareInput method. Is there any way we could directly pass it the Comparison object? Otherwise, we'd be comparing the models twice: once to check the assertEquals assertion, and again for showing the differences.
- The constructor also takes an editing domain and an adapter factory, just like the createCompareEditorInput protected static method in the AbstractCompareHandler class. Looking at CompareInNewEditor#execute, the adapter factory can be easily created, but the editing domain seems trickier: AbstractCompareHandler#createEMFCompareEditingDomain appears to do the job, but it is private.
In summary, I think we'd be fine if EMFCompareEditorInput optionally accepted a precomputed Comparison object instead of computing on the fly and AbstractCompareHandler#createEMFCompareEditingDomain were easier to access. We could create the instance then and pass it over to CompareUI as we did before. Would these changes be OK?
Best regards,
Antonio
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05180 seconds
Home
).