Community
Participate
Working Groups
Created attachment 241961 [details] Screenshots of non-working profile update Used version is Papyrus UML 1.0.0.v201404101527. I planned to test the profile switch but stumbled on this bug first. Updating the profile for a single model works, but updating subsequent models without closing the previously updated model does not work. The model seem to be "half updated" (or something) wrt the version and content of the updated profile. See screenshot. * The profile is updated from version 0.3.3 to version 0.4.1. * One thing that happened between these two version is that the stereotype NWAArea changed name to NWAFunction. * In the Papyrus UI the profile version seem to have been updated to version 0.4.1 and the applied stereotype name updated to NWAFunction. * ...but in the .uml file the profile version is still 0.3.3 (.../32) and the name of the applied stereotype is still NWAArea. This fatal bug is one reason why the new "cleaning function" proposed in Bug 431953 should be run both when opening a model and after a profile has been updated to ensure that the in-memory model of the model is correct before saving it to file. (perhaps also reload the model from file and check again) Perhaps this bug is fixed after 1.0.0.v201404101527, but in any case there should be regression test cases covering this and similar problems.
Created attachment 241963 [details] Test cases for profile update that can be reproduced PW for this one sent to Camille. Attached is a zip with profiles and exported projects containing before-and-after-profile-update versions of models, plus the models where the update failed. Example: * FixedAccess\NWAProfile_version_0.3.3 is the model for profile version 0.3.3. * FixedAccess\NWAProfile_version_0.4.1 is the model successfully updated for version 0.4.1 of the profile, when opening, updating, saving and closing the models one by one. * FixedAccess is the model described in the attached slide. The tests can be run again by manually copying the models under NWAProfile_version_0.3.3 to one level above and refreshing the projects. Then open the models to update to the 0.4.1 version of the profile and then save to disk, one by one, without closing the already updated models.
Trying to reproduce this on a simple profile applied to a couple of models, I see both models correctly migrated with the stereotype name change recognized and the correct Ecore definition applied and instantiated. However, I did get exceptions in the unloading of the affected models before they were re-loaded for migration. Those are reported as bug 432753. Perhaps some exception (thinking especially of a ConcurrentModificationException) bombs the profile re-apply procedure? That could explain the symptoms observed by the reporter. Are there any exceptions in the workspace log that could illuminate the issue?
Which Papyrus version are you using? Apparently you have updated the UML2 component too.
Have you tried the attached test case?
I have reproduced the problem on current Git master (commit 31208d4) in more than one of the models attached by the reporter. I'll investigate the cause. The error log reports no exceptions.
The problem is that the models manifesting this profile migration issue were created before Papyrus adopted the UML 2.5 implementation of the UML2 project, which is why I didn't reproduce it in my own experiment. These models (UML 2.4.1 schema) are loaded using UML2's UML402Resource implementation, not the UMLResource which supports UML 2.5 instances. The factory for the UML402Resource sets the XMLResource.OPTION_EXTENDED_METADATA load option to a particular extended metadata instance, not just Boolean.TRUE. The UML402UMLExtendedMetaData is initialized by the factory with the global package registry, because it doesn't know the resource set context in which the resource will be loaded, so it cannot use the resource set's local registry (as would be the case when setting this option to Boolean.TRUE, as in the UMLResource case). The consequence of this is that the dynamic EPackage definition of the profile (the 0.3.3 version) that is eventually loaded in the resource set is registered in the global package registry. Not good! Any other model subsequently loaded that has the same profile version applied will find that same EPackage instance in the registry and create stereotype applications from its EClasses. The reason why this is a problem is that now all of the stereotype applications in all models loaded in all editors trace back to the same profile in the first editor that was opened. The profile migration API has a check before migrating any stereotype instance that the profile defining it is the same profile that is being re-applied; this is only true in the first editor that was opened. So, none of the other editors actually migrates any stereotype applications because the API thinks they are defined by a different profile. To fix this, we may perhaps somehow ensure that the resource set's local package registry is injected into the UML402UMLExtendedMetaData. But, in any case, it's a bug in UML2 that the resource factory creates an extended metadata instance in the first place, because UML2 should know that profiles may be loaded that have dynamic EPackages that should never be added to the global package registry.
A fix for the UML2 bug 433149 has been pushed and will be available in the next UML2 integration build. The current bug can be resolved when that UML2 build is integrated into the Papyrus build.
The UML2 project has published an integration build with the fix for bug 433149, and it is now picked up by the Papyrus nightly builds.
Tested using Papyrus UML 1.0.0.v201404290454 UML2 Extender SDK 5.0.0.v20140424-0004 and it seems to work fine. :) The model gets "repaired" when opened and the stereotype in the 0.3.3 version of the profile is migrated to the renamed stereotype in the 0.4.1 version. Great job!
(In reply to Toni Siljamäki from comment #9) > > Great job! Thanks for the verification! Please do keep report any further issues in this area; it has turned out more complicated than I had first thought it should.
The mismatch between what the Papurus UI said wrt profile version and stereotype name was found only "by accident" while doing some archeological investigations of the .uml file content. ...not something you do just for the fun of it. :( But we keep our eyes open, of course, and I guess your new "cleaning" function can detect things not found during regression tests.
