[ http://jira.andromda.org/browse/XMLSCHEMA-3?page=comments#action_12668 ]
David Allen commented on XMLSCHEMA-3: ------------------------------------- I should have added a few other items of interest earlier to that long report: 1. Using Ant to build these projects with the nightly binary release has no problems. 2. The XmlSchema cartridge test always passed when building andromda-all with Maven 2. 3. All the other cartridges are working fine with Maven 2. The problems only started once the xmlschema cartridge dependency was added, and the additional model was configured for AndroMDA. > Erratic failures of cartridge with Maven 2 builds > ------------------------------------------------- > > Key: XMLSCHEMA-3 > URL: http://jira.andromda.org/browse/XMLSCHEMA-3 > Project: XML Schema Cartridge > Type: Bug > Environment: Maven 2.0.2, Sun Microsystems Inc.1.5.0_05-b05, V3_x_HEAD > Reporter: David Allen > Assignee: Chad Brandon > Attachments: maven-xml-fatal.txt, xmlSchema.xsd, xmltest.zip > > Having started with an application generated by andromdapp that was working > fine, adding the xmlschema cartridge and a UML model to define an XSD, > erratic build errors occur mostly with the xmlschema cartridge. Sometimes it > reports errors, other times not even when the generated schema clearly had > problems. The behavior is erratic in the sense that each iteration of doing > "mvn clean" then "mvn" does not always produce identical results. In fact, > once in a while, it actually works. > All of the problems always manifest themselves with association end facade > problems. For instance, the schema generated will contain lines (sometimes > just 1 and sometimes all cases) like: > <xsd:element ref="impl:schemaTypeTwo" minOccurs="$otherEnd.minOccurs" > maxOccurs="$otherEnd.maxOccurs"/>. > Most of the time, the cartridge reports no errors; although, a VSL reference > exception is recorded in the andromda-xmlschema.log file. > While trying to debug the problem, I added a log configuration file to the > AndroMDA configuration file that includes the model for processing. This > line looks like: > <property > name="loggingConfigurationUri">file:${andromda.log.config}</property>, which > does work OK in the sense that it does change the logging levels as indicated > in my external log4j.xml file. However, it then changes the behavior of the > xmlschema cartridge at run-time such that right now (it hasn't always done > this) it reports the fatal error (terminating the Maven build) of: > [INFO] Error running AndroMDA > Embedded error: Invocation of method 'getOtherEnd' in class > org.andromda.cartridges.xmlschema.metafacades.XSDAssociationEndLogicImpl > threw exception class java.lang.NullPointerException : null > To limit the problem down to the xmlschema cartridge, I took the POM from the > top level, the POM from the mda directory, the > XmlSchemaCartridgeTestModel.xml.zip (modified to include the 3.2-RC1-SNAPSHOT > version on all profiles) and used this to just run the xmlschema cartridge to > generate a schema file. I also left the other cartridges in the dependencies > as was added by andromdapp when the original project was generated in case > this is some sort of dependency issue. All properties related to other > cartridges were removed to make the POMs smaller since only the xmlschema > cartridge is used in this test. Also, the cartridges were built with the Sun > 1.5.0_05-b05 JDK and Maven 2.0.2 and andromda-all several different days this > week, the latest being March 15 after the binary release was built that night. > The entire project is zipped and will be attached to this bug report shortly > (just a few files and directories). The most reliable way to reproduce the > problem (at least with my builds of AndroMDA) is to comment out the log > configuration in the andromda-xml.xml configuration file in > mda/src/main/config, execute 'mvn'. If that works, put the external log > configuration line back in and do 'mvn' again. It fails for me one way or > the other greater than 90% of the time with the log configuration line, and > fails at least 50% of the time without that line (failure meaning a reported > error or at least a bad schema being produced). > Attachments to follow... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.andromda.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
