Re: Problem with collections test dependency
On 13 September 2010 05:11, Stefan Bodewig bode...@apache.org wrote: On 2010-09-13, sebb wrote: On 13 September 2010 03:36, Bill Barker billwbar...@verizon.net wrote: I thought you had a login account on vmgump. But anyway: I did have on the previous incarnation. If I have one on the current Gump it's not working for me. Do you want one? If possible, yes, it would be useful to have a login again. Is it possible that the test phase is picking up the wrong collections jar somehow? The project commons-collections4 isn't doing an 'install' target, so shouldn't be overwriting commons-collections. However the commons-digester build log shows: Downloading: http://localhost:8192/maven2/commons-collections/commons-collections/2.0/commons-collections-2.0.jar Even if commons-collections4 builds before digester, mvn will not download it but commons-collections built from the 3.x branch because collections4 uses org.apache.commons as groupId. Is there a way to show the classpath used by Surefire? Don't know enough about M2 to answer this one. FWIU CLASSPATH is completely irrelevant for Surefire. Surefire uses what you specify inside your POM, that's it. Not sure I follow - does that mean that Gump does not override the Maven definitions for Surefire? This also means you can add/remove whatever you want to/from the dependencies of any mvn project, it doesn't make any difference. The only thing that matters is build order. Commons-scxml-test [1] fails with the same classpath problem [3],[4],[5], even though collections3 is on the classpath [2] If the Gump descriptor does not affect Surefire, how can Gump be told to use the exact same dependencies for both build and test? [1] http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html [2] http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/details.html [3] http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_file/org.apache.commons.scxml.io.IOTestSuite.txt.html [4] http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_file/org.apache.commons.scxml.model.ModelTestSuite.txt.html [5] http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_file/org.apache.commons.scxml.issues.IssuesTestSuite.txt.html Stefan - 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
Re: Problem with collections test dependency
On 2010-09-13, sebb wrote: On 13 September 2010 05:11, Stefan Bodewig bode...@apache.org wrote: FWIU CLASSPATH is completely irrelevant for Surefire. Surefire uses what you specify inside your POM, that's it. Not sure I follow - does that mean that Gump does not override the Maven definitions for Surefire? Gump can't, mvn doesn't allow it to. Gump installs a proxy between mvn and the central repo (as well as a few well know other repositories) and when mvn asks for an artifact that has already been built by Gump (ignoring versions) the proxy will hand out Gump's jar - otherwise the one from central will be provided. So build order decides what may be available the POM decided what mvn asks for in the first place. You can influence things by pushing a custom POM into the mvn proxy (I've done so for Xalan so that anybody who needs Xalan also requires serializer.jar) but this hasn't been done often so far. If a project asks for commons-collections with groupId commons-collections it will get the one built by Gump from the 3.x branch - if that has already been built - or the one from central. commons-collections4 should never be provided to a project unless mvn is asking for the groupId org.apache.commons. Commons-scxml-test [1] fails with the same classpath problem [3],[4],[5], even though collections3 is on the classpath [2] The root cause is a change in commons-beanutils. http://svn.apache.org/viewvc?view=revisionrevision=995833 SCXML depends on Digester depends on Beanutils. The latter now (in trunk) depends on commons-collections. Digester uses the POM from commons-beanutils in central which only has an optional dependency on commons-collections and the jar built by Gump where it has become non-optional. There are (at least) two solutions: * make Digester explicitly depend on commons-collections (may not help SCXML). * publish commons-beanutils' POM together with the jar to the mvn proxy (just a matter of adding a pom element to the Gump descriptor) so commons-collections ends up being a transitive dependency for digester and scxml. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Problem with collections test dependency
On 13 September 2010 20:41, Stefan Bodewig bode...@apache.org wrote: On 2010-09-13, sebb wrote: On 13 September 2010 05:11, Stefan Bodewig bode...@apache.org wrote: FWIU CLASSPATH is completely irrelevant for Surefire. Surefire uses what you specify inside your POM, that's it. Not sure I follow - does that mean that Gump does not override the Maven definitions for Surefire? Gump can't, mvn doesn't allow it to. Gump installs a proxy between mvn and the central repo (as well as a few well know other repositories) and when mvn asks for an artifact that has already been built by Gump (ignoring versions) the proxy will hand out Gump's jar - otherwise the one from central will be provided. So build order decides what may be available the POM decided what mvn asks for in the first place. You can influence things by pushing a custom POM into the mvn proxy (I've done so for Xalan so that anybody who needs Xalan also requires serializer.jar) but this hasn't been done often so far. If a project asks for commons-collections with groupId commons-collections it will get the one built by Gump from the 3.x branch - if that has already been built - or the one from central. commons-collections4 should never be provided to a project unless mvn is asking for the groupId org.apache.commons. Commons-scxml-test [1] fails with the same classpath problem [3],[4],[5], even though collections3 is on the classpath [2] The root cause is a change in commons-beanutils. http://svn.apache.org/viewvc?view=revisionrevision=995833 SCXML depends on Digester depends on Beanutils. The latter now (in trunk) depends on commons-collections. Digester uses the POM from commons-beanutils in central which only has an optional dependency on commons-collections and the jar built by Gump where it has become non-optional. There are (at least) two solutions: * make Digester explicitly depend on commons-collections (may not help SCXML). Already tried that - does not seem to help. * publish commons-beanutils' POM together with the jar to the mvn proxy (just a matter of adding a pom element to the Gump descriptor) so commons-collections ends up being a transitive dependency for digester and scxml. Now trying that. Stefan - 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
BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 2 notifys should have been sent *** G U M P [g...@vmgump]: Project lucene-java-test (in module lucene-java) failed [g...@vmgump]: Project camel-jms-test (in module camel) failed *** G U M P [g...@vmgump]: Project lucene-java-test (in module lucene-java) 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 gene...@gump.apache.org. Project lucene-java-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: - lucene-java-test : Java Based Search Engine Full details are available at: http://vmgump.apache.org/gump/public/lucene-java/lucene-java-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on javacc exists, no need to add for property javacc.home. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/lucene-java/lucene-java-test/gump_work/build_lucene-java_lucene-java-test.html Work Name: build_lucene-java_lucene-java-test (Type: Build) Work ended in a state of : Failed Elapsed: 9 mins 14 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=13092010 -Djavacc.home=/srv/gump/packages/javacc-3.1 test-core [Working Directory: /srv/gump/public/workspace/lucene-java/lucene] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/lucene-java/lucene/build/classes/test:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/packages/javacc-3.1/bin/lib/javacc.jar:/srv/gump/public/workspace/junit/dist/junit-13092010.jar:/srv/gump/public/workspace/junit/dist/junit-dep-13092010.jar:/srv/gump/public/workspace/lucene-java/lucene/build/lucene-core-13092010.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.036 sec [junit] [junit] Testsuite: org.apache.lucene.search.TestFilteredSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.019 sec [junit] [junit] Testsuite: org.apache.lucene.search.TestNumericRangeQuery64 [junit] Tests run: 33, Failures: 0, Errors: 0, Time elapsed: 8.864 sec [junit] [junit] Testsuite: org.apache.lucene.search.TestPrefixFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.015 sec [junit] [junit] Testsuite: org.apache.lucene.search.TestQueryWrapperFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.148 sec [junit] [junit] Testsuite: org.apache.lucene.search.TestSimilarity [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.043 sec [junit] [junit] Testsuite: org.apache.lucene.search.TestSimpleExplanationsOfNonMatches [junit] Tests run: 53, Failures: 0, Errors: 0, Time elapsed: 0.804 sec [junit] [junit] Testsuite: org.apache.lucene.search.payloads.TestPayloadNearQuery [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.988 sec [junit] [junit] Testsuite: org.apache.lucene.search.spans.TestSpanExplanations [junit] Tests run: 31, Failures: 0, Errors: 0, Time elapsed: 4.406 sec [junit] [junit] Testsuite: org.apache.lucene.store.TestLock [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.025 sec [junit] [junit] Testsuite: org.apache.lucene.store.TestRAMDirectory [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.298 sec [junit] [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.499 sec [junit] [junit] Testsuite: org.apache.lucene.util.TestPriorityQueue [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.061 sec [junit]
Re: Problem with collections test dependency
On 2010-09-14, sebb wrote: On 13 September 2010 20:41, Stefan Bodewig bode...@apache.org wrote: There are (at least) two solutions: * make Digester explicitly depend on commons-collections (may not help SCXML). Already tried that - does not seem to help. What I meant was in Digester's POM, not inside the Gump descriptor. * publish commons-beanutils' POM together with the jar to the mvn proxy (just a matter of adding a pom element to the Gump descriptor) so commons-collections ends up being a transitive dependency for digester and scxml. Now trying that. OK Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
