Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMF Compare] don't ignore children of unmatched elements
[EMF Compare] don't ignore children of unmatched elements [message #662693] Thu, 31 March 2011 15:20 Go to next message
leonard.krpan is currently offline leonard.krpanFriend
Messages: 20
Registered: March 2011
Junior Member
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 #662907 is a reply to message #662693] Fri, 01 April 2011 12:47 Go to previous messageGo to next message
leonard.krpan is currently offline leonard.krpanFriend
Messages: 20
Registered: March 2011
Junior Member
Alrite so I made some progess: I figured out that the problem lies in the fact that in recursiveMappings, when mapList is populated by calling mapLists; the unmatched elements are not added to mapList, therefore in the subsequent recursive call their contents are never explored.

My first thought right now is to put unmatched elements in the list too so that their contents are explored as well, put in the stillToFind instance variable so they can be matched with other non-matched elements later on.
Re: [EMF Compare] don't ignore children of unmatched elements [message #663463 is a reply to message #662693] Tue, 05 April 2011 08:21 Go to previous messageGo to next message
leonard.krpan is currently offline leonard.krpanFriend
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 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
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 Smile.

Laurent Goubet
Obeo
Previous Topic:[Texo] [bug] Texo 0.1.0 does not respect @Temporal annotation model, sticks with DATE
Next Topic:[Teneo] setting Hibernate Interceptor
Goto Forum:
  


Current Time: Fri Mar 29 04:38:56 GMT 2024

Powered by FUDForum. Page generated in 0.04665 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top