Re: Problem with collections test dependency
On 14 September 2010 04:47, Stefan Bodewig bode...@apache.org wrote: 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. I see. Given that Digester does not depend directly on collections, it would be a pain to have to administer collections version changes. * 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 Works! Thanks. 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 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
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
Re: Problem with collections test dependency
-- From: sebb seb...@gmail.com Sent: Sunday, September 12, 2010 5:00 AM To: general@gump.apache.org Subject: Problem with collections test dependency Digester depends on collections, but fails at run-time because the class org/apache/commons/collections/FastHashMap is not present. However, the classpath includes commons-collections-3.3-SNAPSHOT.jar which should include this class. Is there a way to get access to the jar to check its contents? I thought you had a login account on vmgump. But anyway: billbar...@vmgump:~/gump/public/workspace/commons-collections-3.x/target$ jar tf commons-collections-3.3-SNAPSHOT.jar | grep Fast org/apache/commons/collections/FastArrayList$SubList$SubListIter.class org/apache/commons/collections/FastHashMap.class org/apache/commons/collections/FastHashMap$CollectionView$CollectionViewIterator.class org/apache/commons/collections/FastHashMap$EntrySet.class org/apache/commons/collections/FastTreeMap.class org/apache/commons/collections/FastTreeMap$Values.class org/apache/commons/collections/FastTreeMap$1.class org/apache/commons/collections/FastHashMap$Values.class org/apache/commons/collections/FastArrayList.class org/apache/commons/collections/FastArrayList$SubList.class org/apache/commons/collections/FastHashMap$CollectionView.class org/apache/commons/collections/FastHashMap$KeySet.class org/apache/commons/collections/FastTreeMap$EntrySet.class org/apache/commons/collections/FastHashMap$1.class org/apache/commons/collections/FastArrayList$ListIter.class org/apache/commons/collections/FastTreeMap$CollectionView$CollectionViewIterator.class org/apache/commons/collections/FastTreeMap$KeySet.class org/apache/commons/collections/FastTreeMap$CollectionView.class 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 Downloading: http://localhost:8192/maven2/org/codehaus/plexus/plexus-velocity/1.1.3/plexus-velocity-1.1.3.jar 566K downloaded (commons-collections-2.0.jar) Is there a way to show the classpath used by Surefire? Don't know enough about M2 to answer this one. Note that collections4 does not contain FastHashMap. - 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 13 September 2010 03:36, Bill Barker billwbar...@verizon.net wrote: -- From: sebb seb...@gmail.com Sent: Sunday, September 12, 2010 5:00 AM To: general@gump.apache.org Subject: Problem with collections test dependency Digester depends on collections, but fails at run-time because the class org/apache/commons/collections/FastHashMap is not present. However, the classpath includes commons-collections-3.3-SNAPSHOT.jar which should include this class. Is there a way to get access to the jar to check its contents? 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. billbar...@vmgump:~/gump/public/workspace/commons-collections-3.x/target$ jar tf commons-collections-3.3-SNAPSHOT.jar | grep Fast org/apache/commons/collections/FastArrayList$SubList$SubListIter.class org/apache/commons/collections/FastHashMap.class org/apache/commons/collections/FastHashMap$CollectionView$CollectionViewIterator.class org/apache/commons/collections/FastHashMap$EntrySet.class org/apache/commons/collections/FastTreeMap.class org/apache/commons/collections/FastTreeMap$Values.class org/apache/commons/collections/FastTreeMap$1.class org/apache/commons/collections/FastHashMap$Values.class org/apache/commons/collections/FastArrayList.class org/apache/commons/collections/FastArrayList$SubList.class org/apache/commons/collections/FastHashMap$CollectionView.class org/apache/commons/collections/FastHashMap$KeySet.class org/apache/commons/collections/FastTreeMap$EntrySet.class org/apache/commons/collections/FastHashMap$1.class org/apache/commons/collections/FastArrayList$ListIter.class org/apache/commons/collections/FastTreeMap$CollectionView$CollectionViewIterator.class org/apache/commons/collections/FastTreeMap$KeySet.class org/apache/commons/collections/FastTreeMap$CollectionView.class Thanks! 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 Downloading: http://localhost:8192/maven2/org/codehaus/plexus/plexus-velocity/1.1.3/plexus-velocity-1.1.3.jar 566K downloaded (commons-collections-2.0.jar) Is there a way to show the classpath used by Surefire? Don't know enough about M2 to answer this one. Now that the test phase is in a separate project, it seems that the required test dependencies - including collections3 - are missing from the classpath. I'll add / move the dependencies and see if that fixes things. Thanks for confirming that the jar has the correct contents. Note that collections4 does not contain FastHashMap. - 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 - 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 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? 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. 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. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
