Re: [mdr-users] XMI Modules supported by MDR?

Thanks Chad & Martin,
I'll check the archives etc. and use the AndroMDA patch.

Best regards,
Pieter.

On 7/12/05, Chad Brandon <[email protected]> wrote:
> We ended up commenting out the CompositionViolationException in the MDR
> code (that was our work-a-round).  No Magic said they wouldn't fix it
> (the invalid references) until Magic Draw 10.
> 
> Martin Matula wrote:
> 
> > I already wrote you about the CompositionViolationException in one of
> > my previous e-mails. MagicDraw serializes the elements to several
> > files in a wrong way - it puts some kind of proxy element into each
> > file, but these are proprietary - a generic XMI client does not know
> > the elements added by MD are just some kind of proxies that should be
> > matched based on the xmi.id with the element from the remote file. So,
> > the MDR thinks the XMI assigns several containers (composites) to a
> > single element. At least that's what I remember. We were discussing
> > this with Matthias Bohlen and MagicDraw guys and in the end I think it
> > was somehow resolved on the AndroMDA side. You should be able to find
> > some discussion about it on the AndroMDA web pages (I remember
> > Matthias Bohlen logged it somewhere).
> > Martin
> >
> > Pieter Van Gorp wrote:
> >
> >> Hi Martin,
> >> I decided to generate the plain XML file with MagicDraw and guess
> >> what: the prolog exception isn't thrown anymore.
> >>
> >> The UML files are available on
> >> http://www.fots.ua.ac.be/~pvgorp/tmp/mdr/mdrWorksWithProfiles.tar.gz
> >>
> >> Apparently I missed something when I tried to unzip the MagicDraw
> >> files myself and update the hrefs with a search/replace... Thanks for
> >> keeping me thinking in this direction!
> >>
> >> Now the prolog exception is gone, another one came up.  This time it
> >> is an MDR exception instead of an XML parser one.  It is the recurring
> >> (well-known) CompositionViolationException.  If I cannot find its
> >> cause, I'll start a new mail thread on it.
> >>
> >> Thanks again and best regards,
> >> Pieter.
> >>
> >> On 7/12/05, Martin Matula <[email protected]> wrote:
> >>
> >>
> >>> Yes, please send them.
> >>> Martin
> >>>
> >>> Pieter Van Gorp wrote:
> >>>
> >>>
> >>>
> >>>> Hi Martin,
> >>>> I should have sent you some other files since I already checked
> >>>> whether it worked when using plain XML files instead XML.ZIPs... When
> >>>> using plain XML files (as you suggest as well), the same exception is
> >>>> thrown.  I'll send you the plain XML files as well if you like.
> >>>>
> >>>> Regards,
> >>>> Pieter.
> >>>>
> >>>> On 7/12/05, Martin Matula <[email protected]> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Pieter,
> >>>>> modelWithModules.xml contains hrefs of a proprietary format - they
> >>>>> reference zip file - MDR tries to handle files referenced in HREFs as
> >>>>> XML files, since that's how standard hrefs in XMI should work. By
> >>>>> trying
> >>>>> to parse the file referenced from HREF - i.e. the zip file - the XML
> >>>>> parser seems to report this weird message (we are using the
> >>>>> standard XML
> >>>>> parser that is part of the JDK - MDR sources themselves do not
> >>>>> contain
> >>>>> any string literal containing word "prolog" so the message is
> >>>>> really not
> >>>>> generated by MDR). It is obvious that this will end up with an error,
> >>>>> since the file referenced from the hrefs is a binary file, not a
> >>>>> valid XML.
> >>>>> Regards,
> >>>>> Martin
> >>>>>
> >>>>> Pieter Van Gorp wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Hi all,
> >>>>>> coming back to a recent thread, I have prepared a small example that
> >>>>>> illustrates the problem I experienced with MDR.
> >>>>>>
> >>>>>> On http://www.fots.ua.ac.be/~pvgorp/tmp/mdr/ you find
> >>>>>> modelWithoutModules.xml and modelWithModules.xml.  The former is an
> >>>>>> XMI file exported by MagicDraw 9.0 that is correctly processed by
> >>>>>> MDR.
> >>>>>> The latter represents the same UML model but imports profile
> >>>>>> information from an external XMI module file called
> >>>>>> sdm-profile-jcmtg.xml.zip.  Apart from storing the profile in a
> >>>>>> separate file, there should be no changes between
> >>>>>> modelWithModules.xml
> >>>>>> and modelWithoutModules.xml.  MDR throws the "content not allowed in
> >>>>>> prolog" exception when loading modelWithModules.xml.
> >>>>>>
> >>>>>> If you like to execute the problematic situation on your machine,
> >>>>>> you
> >>>>>> can use the code from mdr-modules.tar.gz.  The reason for the large
> >>>>>> file size is that I wanted to make the code executable with minimal
> >>>>>> effort for me and you ;-) Once unzipped, go to the
> >>>>>> mdr-modules/jcmtg/transformer dir and execute (1) ant build-exec,
> >>>>>> (2)
> >>>>>> ant and (3) ant exec.
> >>>>>>
> >>>>>> You can switch between the loading of modelWithModules.xml and
> >>>>>> modelWithoutModules.xml by adjusting the trans.model.xmi.url
> >>>>>> property
> >>>>>> in mdr-modules/jcmtg/transformer/build.properties.
> >>>>>>
> >>>>>> Chad, I tried to use plain XML files only instead of zipped XML
> >>>>>> files
> >>>>>> and I still get the exception, so I'm not sure if using a custom XMI
> >>>>>> reference resolver will solve the problem.
> >>>>>>
> >>>>>> I hope if these sample files help you understand my problem better.
> >>>>>> Please let me know if I should give additional info.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Pieter.
> >>>>>>
> >>>>>> On 6/15/05, Pieter Van Gorp <[email protected]> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Hi Martin, I'll check out Chad's solution first and send my
> >>>>>>> files if
> >>>>>>> that doesn't work for me.
> >>>>>>>
> >>>>>>> Thanks again,
> >>>>>>> Pieter.
> >>>>>>>
> >>>>>>> On 6/14/05, Martin Matula <[email protected]> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> A minimal example would of course be more desirable. Anyway, if
> >>>>>>>> your
> >>>>>>>> files are of a reasonable size for sending them to the mailing
> >>>>>>>> list, I
> >>>>>>>> don't mind...
> >>>>>>>>
> >>>>>>>> Pieter Van Gorp wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Hi Martin,
> >>>>>>>>> shall I post to the list my actual MagicDraw XMI files (profile
> >>>>>>>>> definition and application) or shall I make a minimal example
> >>>>>>>>> that
> >>>>>>>>> still triggers the exception first?
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Pieter.
> >>>>>>>>>
> >>>>>>>>> On 6/14/05, Pieter Van Gorp <[email protected]> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Hi Martin,
> >>>>>>>>>> thanks for your reply:
> >>>>>>>>>>
> >>>>>>>>>> On 6/14/05, Martin Matula <[email protected]> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>> I'm experiencing problems when processing XMI files using
> >>>>>>>>>>>> external
> >>>>>>>>>>>> modules in MDR.  My input file is a UML file in XMI
> >>>>>>>>>>>> generated by
> >>>>>>>>>>>> MagicDraw 9.  The problem occurred after moving my profile
> >>>>>>>>>>>> definitions
> >>>>>>>>>>>> to a separate XMI file.  MDR throws a "Content is not
> >>>>>>>>>>>> allowed in
> >>>>>>>>>>>> prolog" exception.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> That's weird. MDR definitely does not print anything like
> >>>>>>>>>>> that. Maybe
> >>>>>>>>>>> the XML parser does that. Try if the file is a valid XML.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Here's the context of the exception:
> >>>>>>>>>> org.netbeans.lib.jmi.util.DebugException: Content is not
> >>>>>>>>>> allowed in prolog.
> >>>>>>>>>>     at
> >>>>>>>>>> org.netbeans.lib.jmi.xmi.XmiContext.readExternalDocument(XmiContext.java:927)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> When validating with Xerces, I get a lot of "undeclared type"
> >>>>>>>>>> errors
> >>>>>>>>>> although MagicDraw happily opens and saves the file...
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>> I found that AndroMDA contains special code for dealing
> >>>>>>>>>>>> with modules
> >>>>>>>>>>>> (in the
> >>>>>>>>>>>> org.andromda.repositories.mdr.MDRXmiReferenceResolverContext
> >>>>>>>>>>>> class).  Should I follow the same strategy or does MDR provide
> >>>>>>>>>>>> built-in module-support such that I don't have to wrap
> >>>>>>>>>>>> repository
> >>>>>>>>>>>> classes?  For instance, is there one specific MDR method
> >>>>>>>>>>>> that I should
> >>>>>>>>>>>> call after loading an XMI file containing hrefs to elements
> >>>>>>>>>>>> in another
> >>>>>>>>>>>> XMI file to make MDR treat the two XMI files as one large
> >>>>>>>>>>>> model?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> MDR does this automatically.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Good to know... it makes me wonder why AndroMDA uses special XMI
> >>>>>>>>>> resolvers... anyway, I'm still wondering where the "content
> >>>>>>>>>> is not
> >>>>>>>>>> allowed in prolog" exception comes from...
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> In earlier versions of MagicDraw there was
> >>>>>>>>>>> a bug in XMI serialization causing
> >>>>>>>>>>> CompositionViolationException. I
> >>>>>>>>>>> don't know if this was fixed in MagicDraw 9, but so far this
> >>>>>>>>>>> does not
> >>>>>>>>>>> seem to be your problem.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Indeed, in fact I encountered this problem when copying
> >>>>>>>>>> subgraphs
> >>>>>>>>>> across models.  It was not a bug of MagicDraw but a
> >>>>>>>>>> consequence of my
> >>>>>>>>>> way of copying model elements.  I'll come back to that shortly.
> >>>>>>>>>>
> >>>>>>>>>> Best regards,
> >>>>>>>>>> Pieter.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> 
>