Re: [mdr-users] Clustering the UML for Traceability

Pieter Van Gorp <[email protected]> Thu, 4 Aug 2005 15:37:48 +0200
Newsgroups gmane.comp.java.netbeans.modules.mdr.user
Message-ID <[email protected]>
Hi Martin,

On 7/21/05, Martin Matula <[email protected]> wrote:
> >I have a test in which I create a trace between two UML attributes.
> >I'm not sure if I'm using the NB/JMI API right when creating the
> >clustering extent: I create a new extent and pass an array of size one
> >in which the UML application model is stored.  When serializing the
> >trace extent to XMI, no problems are reported but the references to
> >the UML attributes are in fact dangling IDREFs instead of HREFs to the
> >original UML-XMI file.
> MDR writer will never generate hrefs - you have to either serialize
> everything into a single file, or you can create your own implementation
> of XMIReferenceProvider to teach XMI writer to create hrefs.
I don't really need an XMI serialization of the clustering model
(traceability + UML elements).  The only thing I need in XMI is the
UML content.  Therefore, I guess I'm better of with serializing the
clustered XMI extent.

> >Even worse, I get a classcastexception when trying to create a new
> >trace extent to test whether the XMI for the traceability model
> >contains the required information:
> >org.netbeans.api.mdr.CreationFailedException: Cannot instantiate
> >package because of unexpected exception: java.lang.ClassCastException
> >        at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:472)
> >        at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
> >        at be.ac.ua.fots.motmot.prototypes.crossreferences.TestMDR.testReadTraceBetweenUmlAttributes(TestMDR.java:176)
> >
> >
> what version of MDR are you using? I've tried to look at the lines from
> your stacktrace, but e.g. line number 292 in NBMDRepositoryImpl contains
> javadoc, so I guess you are using a different version.
The ClassCastException disappeared after moving the shutdownall method
from JUnit's tearDown to a finalize method. Perhaps calling
shutdownall brought MDR into a state that made it impossible to to
anything with the default repository?

Thanks again for putting me back on track,
-- Pieter.