BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 1 notifys should have been sent *** G U M P [GUMP@vmgump]: Project axiom-dom-test (in module ws-axis2-commons) failed *** G U M P [GUMP@vmgump]: Project axiom-dom-test (in module ws-axis2-commons) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at general@gump.apache.org. Project axiom-dom-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - axiom-dom-test : Common stuff for the WS projects. Full details are available at: http://vmgump.apache.org/gump/public/ws-axis2-commons/axiom-dom-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/ws-axis2-commons/axiom/modules/axiom-dom/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/ws-axis2-commons/axiom/modules/axiom-dom/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/ws-axis2-commons/axiom/modules/axiom-dom/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/ws-axis2-commons/axiom/modules/axiom-dom/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/ws-axis2-commons/axiom-dom-test/gump_work/build_ws-axis2-commons_axiom-dom-test.html Work Name: build_ws-axis2-commons_axiom-dom-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 12 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/ws-axis2-commons/axiom/modules/axiom-dom/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/ws-axis2-commons/axiom/modules/axiom-dom] M2_HOME: /opt/maven2 - Running org.apache.axiom.om.impl.dom.DOMImplementationTest Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor Tests run: 68, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 2.7 sec FAILURE! Running org.apache.axiom.om.impl.dom.DocumentImplTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.156 sec Running org.apache.axiom.om.impl.dom.OMDOMImplementationTest Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec Running org.apache.axiom.om.impl.dom.factory.DOMFeatureTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Running org.apache.axiom.om.impl.dom.OMXMLParserWrapperTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.079 sec Running org.apache.axiom.om.impl.dom.DocumentImplSerializationTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.axiom.om.impl.dom.OMImplementationTest Apr 14, 2012 6:58:19 PM org.apache.axiom.om.impl.builder.StAXOMBuilder parserNext WARNING: Attempt to access a parser that has thrown a parse exception before; rethrowing the original exception. Apr 14, 2012 6:58:19 PM org.apache.axiom.om.impl.builder.StAXOMBuilder parserNext WARNING: Attempt to access a parser that has thrown a parse exception before; rethrowing the original exception. Apr 14, 2012 6:58:23 PM org.apache.axiom.om.impl.dom.ElementImpl declareNamespace WARNING: Deprecated usage of OMElement#declareNamespace(String,String) with empty prefix Tests run: 618, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.837 sec Running org.apache.axiom.om.impl.dom.CommonImplTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.axiom.om.impl.dom.SOAPEnvelopeTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.axiom.om.impl.jaxp.StreamSourceToOMResultTest Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.204 sec Results : Tests in error: org.apache.axiom.ts.dom.document.TestTransformerWithIdentityStylesheet [transformerFactory=org.apache.xalan.processor.TransformerFactoryImpl](org.apache.axiom.ts.dom.document.TestTransformerWithIdentityStylesheet): Caught exception during comparison org.apache.axiom.ts.dom.document.TestTransformerWithIdentityStylesheet [transformerFactory=net.sf.saxon.TransformerFactoryImpl](org.apache.axiom.ts.dom.document.TestTransformerWithIdentityStylesheet): Caught exception during comparison Tests run: 923, Failures: 0, Errors: 2, Skipped: 0 [INFO] [ERROR] BUILD
xml-commons RIP
It seems that xml-commons' repository has gone away. I found this out while testing a local version of Gump that had no checkouts. Given that it is stale, and in the boot-classpath of just about every ant project, it should go away for modern JVMs. I just want opinions on options. As I see it the choices are: 1) leave the stale projects, but remove the boot attribute. Upside, least amount of work. Downside, nobody will be able to set up a fresh Gump. 2) make the projects empty, and think of something for the couple of projects that have a property .../ depend (or just let them fail). 3) remove it completely and edit a large number of projects that refer to it 4) Ignore the problem completely until there is a break with the JVM. My personal preference is in order 2,1,4,3, but want to hear other opinions first. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: xml-commons RIP
2012/4/15 Bill Barker billwbar...@verizon.net: It seems that xml-commons' repository has gone away. I found this out while testing a local version of Gump that had no checkouts. Given that it is stale, and in the boot-classpath of just about every ant project, it should go away for modern JVMs. I just want opinions on options. As I see it the choices are: 1) leave the stale projects, but remove the boot attribute. Upside, least amount of work. Downside, nobody will be able to set up a fresh Gump. 2) make the projects empty, and think of something for the couple of projects that have a property .../ depend (or just let them fail). 3) remove it completely and edit a large number of projects that refer to it 4) Ignore the problem completely until there is a break with the JVM. My personal preference is in order 2,1,4,3, but want to hear other opinions first. I did not find it in ASF Attic so I went on looking into svn log. So I see that it was moved into /xerces/xml-commons: http://svn.apache.org/viewvc?view=revisionrevision=1311708 http://svn.apache.org/viewvc/xerces/xml-commons/trunk/ About the above list of options : I do not understand what you meant by 2). You clear the metadata file of that module? Or you meant start over with empty list of modules in profile/gump.xml? Regarding 3) the only projects that explicitly refer to xml-commons are ant, ant-1.8.x, xml-xerces2. That is not much. The rest should be an indirect dependency. I wonder whether Ant really needs it. When dealing with svn repositories it is also possible to 5) freeze them in time by setting certain peg and operative revisions. I do not know whether Gump supports that (as it defeats its purpose), but it might be doable. If those repository paths are passed to command-line client as is, this syntax might be already working: svn repository=asf dir=xml/commons/trunk@1311707/ I am not doing any updates to the metadata now - I think you would better try on a standalone Gump that you have, because so many projects depend on it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: xml-commons RIP
-Original Message- From: Konstantin Kolinko Sent: Saturday, April 14, 2012 7:47 PM To: Gump code and data Subject: Re: xml-commons RIP 2012/4/15 Bill Barker billwbar...@verizon.net: It seems that xml-commons' repository has gone away. I found this out while testing a local version of Gump that had no checkouts. Given that it is stale, and in the boot-classpath of just about every ant project, it should go away for modern JVMs. I just want opinions on options. As I see it the choices are: 1) leave the stale projects, but remove the boot attribute. Upside, least amount of work. Downside, nobody will be able to set up a fresh Gump. 2) make the projects empty, and think of something for the couple of projects that have a property .../ depend (or just let them fail). 3) remove it completely and edit a large number of projects that refer to it 4) Ignore the problem completely until there is a break with the JVM. My personal preference is in order 2,1,4,3, but want to hear other opinions first. I did not find it in ASF Attic so I went on looking into svn log. So I see that it was moved into /xerces/xml-commons: http://svn.apache.org/viewvc?view=revisionrevision=1311708 http://svn.apache.org/viewvc/xerces/xml-commons/trunk/ About the above list of options : I do not understand what you meant by 2). You clear the metadata file of that module? Or you meant start over with empty list of modules in profile/gump.xml? Regarding 3) the only projects that explicitly refer to xml-commons are ant, ant-1.8.x, xml-xerces2. That is not much. The rest should be an indirect dependency. I wonder whether Ant really needs it. When dealing with svn repositories it is also possible to 5) freeze them in time by setting certain peg and operative revisions. I do not know whether Gump supports that (as it defeats its purpose), but it might be doable. If those repository paths are passed to command-line client as is, this syntax might be already working: svn repository=asf dir=xml/commons/trunk@1311707/ I am not doing any updates to the metadata now - I think you would better try on a standalone Gump that you have, because so many projects depend on it. Best regards, Konstantin Kolinko Well, you did more research than me :). So that gives the option 6) reset the svn .../ tag to point to the new location That would make 6) my favorite now, but still wonder if xml-api should still be on the boot classpath anymore with modern JVMs. By 2) I meant something like : project name=xml-api /project in the Gump metadata. It will resolve for the couple hundred ant projects that use it, but use the JVM's xml parser. There are a couple of old (and largely dead) projects that reference a project in xml-api via a property .../ tag. And almost every ant build references it since it (used to be) needed at runtime to boot up ant. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
