|
|
Re: [EMF Compare] don't ignore children of unmatched elements [message #663463 is a reply to message #662693] |
Tue, 05 April 2011 08:21 |
leonard.krpan Messages: 20 Registered: March 2011 |
Junior Member |
|
|
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...
|
|
|
Re: [EMF Compare] don't ignore children of unmatched elements [message #665079 is a reply to message #662693] |
Wed, 13 April 2011 08:31 |
|
Hi, and sorry for the delay.
I don't know where you currently stand in your evaluation, but the GenericMatchEngine provided by EMF Compare does not support matching elements under unmatched containers. We do detect "moves" when the container of the moved object is present in both target and source. However, whenever we hit an unmatched object (the package in your case), we stop walking the tree and EMF Compare will simply tell that the container has been removed (or added), along with all of its content.
As you surmised, you will need to override the default behavior from the GenericMatchEngine in order to change this... but I must admit that I don't really know how : we never took this potential issue into account and thus coded with absolutely no thought in how to allow subclass to change this "pruning" behavior.
Most of our algorithms for unmatched element processing (and matching between unmatched elements) is private in the GenericMatchEngine. If you think that making some of these protected so that a subclass could kick in and provide its own unmatched processing behavior, please open a bugzilla entry with the information on what you seek to do, and how... and possibly a patch if you have tried it for yourself and made it work .
Laurent Goubet
Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.04665 seconds