Community
Participate
Working Groups
Latest UML2 Luna (git master commit 32efbfa) 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 factory). The consequence of this is that the dynamic EPackage definition of a profile that is eventually loaded in the resource set is registered in the global package registry. Any other model subsequently loaded in another resource set 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 different resource sets trace back to the same profile in the first resource set. If the EPackage in question is not the latest definition of the profile, then migration to the current version will only work in the first resource set. 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 resource set that loaded the copy of the profile that was put in the global package registry.
Thanks, Christian. I think creating a package registry that’s local to the resource factory (like the other legacy resource factories do) should solve the problem: EPackage.Registry ePackageRegistry = new EPackageRegistryImpl(EPackage.Registry.INSTANCE); Do you agree?
That's exactly the change that makes my new unit tests pass, which I was going to ask you to review. :-)
Fixed in commit a143d4d.
An integration build containing the fix is now available.
