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

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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>          
>>>>>
>>    
>>