Community
Participate
Working Groups
For the last ballot for UML 2.4 ending in 3 days from now, I have created many diagrams with RSA 7.5 for UML's infrastructure & superstructure. I've done dozens of package merges with the help of the fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=313837 I was in package merge heaven until I updated the model to reflect the resolution for OMG issue 13993: http://www.omg.org/issues/issue13993.txt The resolution we just finished today involves separating PrimitiveTypes from the InfrastructureLibrary, thus requiring updating all of the package merge maps. Now, all package merges fail, including the simplest of all, L0 The problem is subtle but it's been out in the open for several years in: org.eclipse.uml2.uml.util.UMLUtil.PackageMerger.merge(Package, Map<String, String>, DiagnosticChain, Map<Object, Object>) public Map<EObject, List<EObject>> merge( org.eclipse.uml2.uml.Package package_, Map<String, String> options, DiagnosticChain diagnostics, Map<Object, Object> context) { receivingPackage = package_; mergedPackages = getAllMergedPackages(package_); copyAll(mergedPackages); copyReferences(); receivingPackage.getPackageMerges().clear(); if (options != null) { processOptions(options, diagnostics, context); } return resultingToMergedEObjectMap; } As written, the code implicitly assumes that clearing the Package::receivingPackage collection will be enough to delete the PackageMerge relationships. As long as we've been merging UML infrastructure/superstructure that had no diagrams this code didn't create any problems because by removing the unique in a model to a PackageMerge element was enough to effectively delete it from the model. Since we've been using RSA 7.5 to do the diagrams and RSA uses the GMF notation metamodel to store diagrams as instances of the notation metamodel, every element/relationship in the model shown in a specific diagram has an extra reference from the GMF node/edge showing the element/relationship. When an RSA diagram shows a package merge relationship from the model, the extra reference to the UML::PackageMerge relationship due to the GMF edge object is enough to alter the behavior of the code above where the UML::PackageMerge element is no longer deleted from the model but left dangling without being logically part of the extent of the model. To experience this problem, load the models attached: InfrastructureLibrary.uml, PrimitiveTypes.uml and L0.uml. Open L0.uml and merge the L0 package with default options. Then, try to save the model; this will trigger a Dangling HREF exception. Before saving, you can also try to validate the model; this time, you'll get a cleaner message about a GMF edge object having a dangling reference to a package merge relationship. With the simple attached patch, everything works properly. Of course, the diagram in the merged model have lost their reference(s) to the PackageMerge elements that have been deleted but that is to be expected.
Created attachment 170446 [details] UML 2.4 Infrastructure Library (test example)
Created attachment 170447 [details] UML 2.4 PrimitiveTypes library (test example)
Created attachment 170448 [details] UML 2.4 L0 package merge map. Try merging this model and then either validating or saving the model to reproduce this bug.
Created attachment 170449 [details] Patch
Created attachment 170574 [details] alternative patch Here's a slightly different patch. Please confirm that this meets your needs.
Thanks Kenn! This works just fine. We can merge UML 2.4 any way we want, before removing tool-specific content (e.g., diagrams) or after (i.e., diagrams stay in the resulting package) With this, Eclipse UML2 unconditionally supports the metamodeling workflows involved in the production of OMG UML 2.4. Of course, this doesn't mean that Eclipse UML2 provides support for OMG UML 2.4 itself; only that the metamodeling machinery needed to produce it works as advertised and in compliance with the fine print of the OMG specifications.
The changes have been committed to CVS.
This fix is available in 3.1.0 RC4.
Excellent! This turns out to be useful because merging the UML with diagrams does preserve in the resulting model the diagram information. Of course, if we do the conversion prior to merging, then we'd be able to merge without this fix but then we loose much more information that may be useful for other purposes.