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.