| [EMF Compare] don't ignore children of unmatched elements [message #662693] |
Thu, 31 March 2011 11:20  |
Eclipse User |
|
|
|
Hello,
I'm using EMF Compare to compare and display changed between an arbitrary number of models. The difference to standard Compare is that the strucutres in which the differences are displayed have been extended specifically for the project. This was done by a person who is not availiable any more, whereas I'm supposed to use the results as input for my own project.
As far as matching goes (which is always two-way) the org.eclipse.emf.compare.match.engine.GenericMatchEngine is used. I read in the documentation left by the person that Generic Match Engine ignores the content of elements which were not matched. I'm working with models that are evolutions of each other - meaning that they are generally similar, but structural changes where in the new version a class gets moved to a package which didn't exist in the old version are possible. In this case, the algorithm couldn't match this class and in the result it would say it was removed, which is not correct. It is crucial that the result contains correct information about all the classes across all models.
Where do I need to look in the GenericMatchEngine in order to disable the described behavior (by creating a customized engine and overwriting this behavior) - so that content under unmatched elements is not ignored?
|
|
|
|
| Re: [EMF Compare] don't ignore children of unmatched elements [message #663463 is a reply to message #662693] |
Tue, 05 April 2011 04:21  |
| Eclipse User |
|
|
|
Hello,
so I have been thinking about this issue for a couple of days now and trying out various solutions.
My initial idea was to simply add unmatched packages to the mapList anyways and use a programmatically created "mock package" as their match. This would cause an exception eventually, because the mock package doesn't exist in any of the models. Also, this solution didn't work very well with the initial packages' subpackages and their content.
The next idea was when a package cannot be matched to add all its subpackages and classifiers to the notFoundList so they can possibly be matched in the second run. For some reason, this caused some packages to appear as multiple, empty DiffGroups. I am going to investigate this case a little more.
Also, I realized that matching objects whose container/parent could not be matched is pretty tricky because these objects are kinda just "hanging loose" there...
Then my colleague (who is not available any more) implemented a solution where in the preprocessing step he simply inserts packages (without their content) into the models, so that the matching algorithm picks up on their contents. However, I saw that in the matchmodel each of these packages matches with "null", and this reflects in the diff too (I get a DiffGroup around "EObject" and cannot trace the actual object behind it). I don't understand why this happens, because while debugging the matching algorithm these packages were matched just fine...
|
|
|
|
Powered by
FUDForum. Page generated in 0.04144 seconds
Home
.