You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by sebb <se...@gmail.com> on 2010/09/12 14:00:06 UTC

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?

Is it possible that the test phase is picking up the wrong collections
jar somehow?
Is there a way to show the classpath used by Surefire?

Note that collections4 does not contain FastHashMap.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Problem with collections test dependency

Posted by sebb <se...@gmail.com>.
On 14 September 2010 04:47, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-09-14, sebb wrote:
>
>> On 13 September 2010 20:41, Stefan Bodewig <bo...@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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Problem with collections test dependency

Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-09-14, sebb wrote:

> On 13 September 2010 20:41, Stefan Bodewig <bo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Problem with collections test dependency

Posted by sebb <se...@gmail.com>.
On 13 September 2010 20:41, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-09-13, sebb wrote:
>
>> On 13 September 2010 05:11, Stefan Bodewig <bo...@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=revision&revision=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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Problem with collections test dependency

Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-09-13, sebb wrote:

> On 13 September 2010 05:11, Stefan Bodewig <bo...@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=revision&revision=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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Problem with collections test dependency

Posted by sebb <se...@gmail.com>.
On 13 September 2010 05:11, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-09-13, sebb wrote:
>
>> On 13 September 2010 03:36, Bill Barker <bi...@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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Problem with collections test dependency

Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-09-13, sebb wrote:

> On 13 September 2010 03:36, Bill Barker <bi...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Problem with collections test dependency

Posted by sebb <se...@gmail.com>.
On 13 September 2010 03:36, Bill Barker <bi...@verizon.net> wrote:
>
>
> --------------------------------------------------
> From: "sebb" <se...@gmail.com>
> Sent: Sunday, September 12, 2010 5:00 AM
> To: <ge...@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.

>
> billbarker@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-unsubscribe@gump.apache.org
>> For additional commands, e-mail: general-help@gump.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Re: Problem with collections test dependency

Posted by Bill Barker <bi...@verizon.net>.

--------------------------------------------------
From: "sebb" <se...@gmail.com>
Sent: Sunday, September 12, 2010 5:00 AM
To: <ge...@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:

billbarker@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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org