Community
Participate
Working Groups
EMF Compare should support the comparison of two models that have different versions of the same profile / stereotypes applied. Currently, the UML PostProcessor only produces a diagnostic error to inform the user that the profile definition has changed if the packages referenced by the profile application don’t line up. However, in many cases, the changes between the profile versions are minor and many stereotypes and attributes remain the same. In such a scenario, I would expect that EMF Compare attempts to compare the models based on the available information. Additionally, EMF Compare may try to migrate the profile automatically to the latest version, in case the old profile is not available anymore. Such a migration scenario is also supported by Papyrus which opens a profile migration / stereotype repair dialog when the user opens a model with outdated stereotype applications. The user is then triggered to select the current package containing the newer versions of the stereotypes to repair the stereotypes / profile application. I suggest to integrate this migration procedure available in Papyrus into EMF Compare to allow for a comparison among models with different applied profiles versions.
Created attachment 262186 [details] SysML model with artificially low version number
I am currently working on such an automated migration procedure by reusing the Papyrus ZombieStereotypesDescriptor functionality. As mentioned in the documentation, essentially, each profile applied to a model maps to an XML schema namespace which, upon loading a model, must be resolvable in the form of an EPackage located either in a deployed plug-in or embedded in the UML profile, itself. The ZombieStereotypesDescriptor can analyze the stereotype applications of a model based on a given set of applied profile definitions and find stereotype applications for which the defining package cannot be found anymore (zombies) and stereotype applications for which the base element has been removed (orphans). The suggested action for zombies is to migrate to a newer (or existing) version of the profile and the suggested action for orphans is to remove them. Our first prototypical integration into EMF Compare looks promising and shows good results. However, there’s a problem when I want to migrate multiple profile applications (multiple profile packages): The ZombieStereotypesDescriptor automatically deletes the up to now unresolved stereotypes of another profile application which would be migrated in the next step. In my example model (see attachment), I have a SysML model with an artificially low version number, i.e., the package URI is http://www.eclipse.org/papyrus/0.6.0/SysML#//modelelements instead of http://www.eclipse.org/papyrus/0.7.0/SysML#//modelelements. The model has two stereotype applications on the same class: Block from the SysML Blocks-Package and ViewPoint from the SysML ModelElements package. Now, the ZombieStereotypesDescriptor correctly identifies the http://www.eclipse.org/papyrus/0.6.0/SysML/Blocks and http://www.eclipse.org/papyrus/0.6.0/SysML/ModelElements EPackages as missing. Please note that here it seems that the profile URIs are taken and not the EPackage URIs. However, the ZombieStereotypesDescriptor reports that both stereotype applications belong to both packages. Therefore, if I start to migrate the Blocks package to the newer version, the correctly identified Block-Stereotype gets migrated, but the ViewPoint-Stereotype gets incorrectly deleted, as all "old" stereotype applications belonging to a package get deleted at the end of the package migration no matter whether a migrated version of them could be produced or not. Maybe ZombieStereotypesDescriptor is not a good entry point. Is there another way how we can use the API to migrate profiles without the deletion of some of the stereotypes?
New Gerrit change created: https://git.eclipse.org/r/75305
New Gerrit change created: https://git.eclipse.org/r/75402
Gerrit change https://git.eclipse.org/r/75402 was merged to [master]. Commit: http://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/commit/?id=38670759ff36933a0bce2de15f4d878b62d8c854
With the provided change, the profile migration mechanism of Papyrus is supported in EMF Compare, i.e., if a profile cannot be found we search for a possible substitute in the registry. Local workspace profiles are currently not considered. Please let me know if there is a demand to also have support for this kind of profiles.
Feel free to reopen if there is a request for local workspace profiles.
