Eclipse Community Forums: Compare » Standard PostProcessor to handle Refactor Rename ?

Help

Home

Home » Modeling » Compare » Standard PostProcessor to handle Refactor Rename ?

Show: Today's Messages :: Show Polls :: Message Navigator

Standard PostProcessor to handle Refactor Rename ? [message #1816559]

Thu, 31 October 2019 10:47

Steve Hickman

Messages: 56
Registered: August 2017

Member

Refactor Rename is a common occurrence in EMF models.
Models developed in XText typically use fully qualified names for identity, rather than XMI GUIDS.
As a result, changing the name is not an attribute change - A rename in a model that uses names for IDs results in both an ADD and DELETE ReferenceChangeSpec for the container of the object renamed, as well as CHANGE ReferenceChangeSpecs for each updated cross reference.

All of these changes should be grouped together because they are really all the same change.

It seems like this is so common that there should already exist code (a PostProcessor class?) that handles this. Further, such a PostProcessor would be a great tutorial on how to work with EMF Compare.

Does such a thing exist? If so, where can I find it?

Report message to a moderator

Re: Standard PostProcessor to handle Refactor Rename ? [message #1816652 is a reply to message #1816559]

Mon, 04 November 2019 08:45

Laurent Goubet

Messages: 1902
Registered: July 2009

Senior Member

Hello,

No, this does not exist. For a generic tool such as EMF Compare, Identity changes mean two different objects, not a renamed object. Xtext doesn't use proper identifiers for its objects so indeed the qualified name becomes the mean to tell the object's identity... but that's only true for Xtext and it's not always true either (when have two objects with no content or very similar content, one on each side, it is very questionable whether you wish to see these as a "rename" or as an actual "added new object and deleted old one).

You can for sure develop a post-processor that will detect such renames in your use cases, the API should be open enough to tackle this need and you can raise bugs for us to open more of the API if some required parts are not available. imho, you have a few ways to go around this. As you mentionned, you could use a post-processor (see the doc on that) to add refine the diff so that you have a diff refining the ones corresponding to the rename and have them hidden from view through filtering, only showing your refine (you can look at what we did with the UML integration to refine the 4/5 differences corresponding to the addition of an association or the ones generated by the addition of a stereotype). The other way would be to directly alter the equality mechanism of EMF Compare so that we "match" the two objects which identity has changed if you have an algorithm to accurately detect them. To this end, you can look at the org.eclipse.emf.compare.rcp.equalityHelperExtensionProvider extension point.

Regards,

Laurent Goubet
Obeo

Report message to a moderator