This is really for the historical record more than anything else, so you can
stop reading now if you're not interested in MagicDraw trivia. Also,
apologies for the HTML, but it makes the formatting a little clearer in this
case.
We've known for a long time that NetBeans MDR considers the MagicDraw
projects which use the MagicDraw "modules" functionality to be invalid.
Unfortunately AndroMDA choose to use this for their modeling profile, so we
had to create a flattened version of it which is extra work and a nuisance
to keep in sync.
I never really knew what the problem was and just repeated the vague second
hand description passed on from the AndroMDA developers that they'd
"commented out some exception" and everything was fine. Since I was working
on the XmiReferenceResolver anyway to fully support multi-file projects (we
stole our from AndroMDA and they only care about reading projects, not
reading & writing as we need), I decided to look at what the real problem
is.
Below is a snippet from the top level profile. Notice that the 'datatype'
package is actually contained in a separate file referenced using a href.
<UML:Model xmi.id='eee_1045467100313_135436_1' name='Data'>
<UML:Namespace.ownedElement>
<UML:Package
href='andromda-profile-datatype-3.2-SNAPSHOT.xml.zip|_9_0_1fe00f9_1119336925
546_238419_77'>
<XMI.extension xmi.extender='MagicDraw UML 9.5'
xmi.extenderID='MagicDraw UML 9.5'>
<referentPath xmi.value='::datatype'/>
</XMI.extension>
</UML:Package>
Now if we look at the definition of the 'datatype' package in the referenced
XMI file, we see the following:
<UML:Model xmi.id='eee_1045467100313_135436_1' name='Data'>
<UML:Namespace.ownedElement>
<UML:Package xmi.id='_9_0_1fe00f9_1119336925546_238419_77'
name='datatype'>
<XMI.extension xmi.extender='MagicDraw UML 9.0'
xmi.extenderID='MagicDraw UML 9.0'>
<moduleRoot xmi.value='::datatype'/>
</XMI.extension>
Although the two files each have a top level Model called 'Data' with the
same xmi.id value, they are different elements since they occur in different
XMI files. The way MagicDraw has set things up though, the 'datatype'
package is contained in the 'ownedElements' composition of two different
Models which is why MDR correctly throws a CompositionViolationException.
MagicDraw apparently does some special management during loading to manage
these "modules" as virtually overlaid in the same package hierarchy using
information from their XMI.extension elements. Unfortunately, it's a)
non-standard and b) not something we can replicate because MDR doesn't read
the XMI.extension elements (since they're a pure XMI thing, not a MOF
thing).
I can detect the upcoming CompositionViolationException in the
XmiReferenceResolver and avoid it by not registering the Package the second
time which would allow us to at least load the models, although they won't
be faithful to the intended package structure. Instead of a single overlaid
hierarchy, we'll end up with N parallel hierarchies with the same package
names. That would at least allow the user the opportunity of migrating the
model to a valid structure that we can process, but it wouldn't allow for
roundtripping between ArgoUML and MagicDraw.
And now you know more than you ever wanted to about why this has always
failed...
Tom
