Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EMF Compare/UML Compare"
| Line 9: | Line 9: | ||
The first one should be simpler as it uses a builtin mechanism of EMFcompare but with less ability to get out of the border of what it had been designed for while the second one would let us define whatever we want but with an increased implementation complexity. | The first one should be simpler as it uses a builtin mechanism of EMFcompare but with less ability to get out of the border of what it had been designed for while the second one would let us define whatever we want but with an increased implementation complexity. | ||
| − | We now detail the two options, their pros and cons, and finally | + | We now detail the two options, their pros and cons, and finally conclude and propose a solution. |
== Builtin extension mechanism == | == Builtin extension mechanism == | ||
| + | |||
| + | The extension mechanism is not working in essence. | ||
== Implements specific Diff/Match engine == | == Implements specific Diff/Match engine == | ||
Revision as of 04:26, 14 April 2011
The primary goal of this section is to provide technical specification of the UML Comparison engine. This engine will provide support of UML specific concepts and operations.
Contents
Overview
There are two ways of implementing UML Compare engine:
- Use the provided extension mechanism and override the visit() method to implement UML specific difference semantic
- Implement our own Diff/Match Engine (or override Generic Diff/Mathc engine if suited) to implement specific diff detection.
The first one should be simpler as it uses a builtin mechanism of EMFcompare but with less ability to get out of the border of what it had been designed for while the second one would let us define whatever we want but with an increased implementation complexity.
We now detail the two options, their pros and cons, and finally conclude and propose a solution.
Builtin extension mechanism
The extension mechanism is not working in essence.
Implements specific Diff/Match engine
The shame is that (from our comprehension), the extension mechanism does not work (we will explain that hereafter) and even if it could be made working by some fixes, it does not scale well in essence.
- Suggestion*
Make the *AbstractDiffExtension#visit()* method deprecated in EMF Compare 1.2 and remove it from 2.0
The GenericXXXEngine (where XXX is Match or Diff) implementations provide useful base implementation of EMF model comparison. Then we will
UML Compare match engine
There is no need to subclass