You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Nigel Magnay <ni...@gmail.com> on 2006/12/08 11:37:19 UTC
surefire transitive classpath bug ?
I think this is a bug in surefire. If I run my project with mvn -X I see in
the output :
[DEBUG] Retrieving parent-POM:
org.apache.myfaces.maven:myfaces-master::1.0.2 for project:
org.apache.myfaces.core:myfaces-core-project:pom:1.1. from the repository.
[DEBUG] org.apache.myfaces.core:myfaces-impl:jar:1.1.3:compile(selected
for compile)
[DEBUG] commons-codec:commons-codec:jar:1.3:compile (selected for
compile)
[DEBUG]
commons-collections:commons-collections:jar:3.1:compile(selected for
compile)
[DEBUG] commons-logging:commons-logging:jar:1.0.4:compile (selected
forcompile)
[DEBUG] commons-el:commons-el:jar:1.0:compile (selected for compile)
[DEBUG] commons-logging:commons-logging:jar:1.0.3:compile (removed
- nearer found: 1.0.4)
....
[DEBUG] org.apache.myfaces.core:myfaces-api:jar:1.1.3:compile(selected
for compile)
[DEBUG] javax.servlet:jstl:jar:1.1.0:compile (selected for compile)
[DEBUG] commons-digester:commons-digester:jar:1.6:compile (selected
for compile)
[DEBUG]
commons-beanutils:commons-beanutils:jar:1.6:compile(selected for
compile)
[DEBUG] commons-logging:commons-logging:jar:1.0:compile (removed
- nearer found: 1.0.4)
[DEBUG]
commons-collections:commons-collections:jar:2.0:compile(removed -
nearer found:
3.1)
...
[DEBUG] org.springframework:spring:jar:2.0:compile (selected for
compile)
[DEBUG] commons-logging:commons-logging:jar:1.0.4:compile (removed -
nearer found: 1.1)
[DEBUG] commons-logging:commons-logging:jar:1.1:compile (selected for
compile)
[DEBUG]
avalon-framework:avalon-framework:jar:4.1.3:compile(selected for
compile)
[DEBUG] javax.servlet:servlet-api:jar:2.3:compile (selected for
compile)
[DEBUG] commons-logging:commons-logging:jar:1.0:compile (removed -
nearer found: 1.0.4)
... etc., etc
However, the version of commons-logging that appears in my classpath for
test is 1.0.4, NOT 1.1 as it appears that it ought to be. Additionally, this
means that avalon-framework is not present in my surefire test classpath,
causing tests to break.
Re: surefire transitive classpath bug ?
Posted by Lee Meador <le...@leemeador.com>.
The real problem is that your application several dependencies and they have
dependencies and sor forth AND when you follow out that tree of dependencies
you find several versions of common logging. I see 1.0, 1.0.4 and 1.1 but I
may be missing some.
When that happens there is no definite way to build the appliation. Which of
those versions should be used?
The best way is for you to add a dependency to your application that tells
which version to use. If your application has several jars that get built,
more than one of those may need a specific version defined in the pom for
that jar. (I suspect it is possible to come up with a build that is
impossible to do because two dependencies absolutely require their own,
disparte versions of a sub-dependency. I haven't run into this myself.)
If you don't provide this guidance for maven to use while building, there
are rules built in that it uses to try to guess which version to choose.
Like you said there is a hash map and the phase of the moon that interfere.
This is becasue something about the built-in maven rules causes it to make
different choice based on which of the dependencies it evaluates first.
I think this indeterminacy is a good thing. It did drive me nuts until I
realized the cause is my own failure to pick an appropriate version. But, if
it always built in the same order a random change in a pom would uncomver
the mismatch. It would hide the mismatch of versions until someday, when I
was under the gun to fix some production problem with the company losing
millions of dollars an hour, when I made a change that caused the mismatch
to bite me.
-- Lee
On 12/8/06, Nigel Magnay <ni...@gmail.com> wrote:
>
> But the -X shows 2 lines for commons-logging, both claiming to be selected
> for compile:
>
> [DEBUG] commons-logging:commons-logging:jar:1.1:compile (selected
> for
> compile)
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:compile (selected
> for compile)
>
> Though actually the compile works, it's the tests that don't. This is
> actually not because of commons-logging, but one of the dependencies that
> 1.1 includes, but 1.0.4 does not.
>
> I also have another problem elsewhere where tests *randomly* fail, because
> commons-lang isn't on the test classpath, even though it's the very first
> jar file specified in the POM!
>
> This leads me to suspect that the dependencies are being stuffed in a
> hashmap somewhere, and dependent upon the phase of the moon, one
> particular
> version 'wins'. This has basically destroyed our ability to do CI builds,
> and developers must 'mvn install - if tests fail, rinse, repeat'.
>
> I'll file a JIRA with full -X output; I've been testing with surefire
> 2.3-SNAPSHOT which may be better. As is always the case with these things,
> turning on -X tends to make it work ;-S
>
>
>
> On 08/12/06, Wendy Smoak <ws...@gmail.com> wrote:
> >
> > On 12/8/06, Nigel Magnay <ni...@gmail.com> wrote:
> >
> > > I think this is a bug in surefire. If I run my project with mvn -X I
> see
> > in
> > > the output :
> > ...
> > > [DEBUG] commons-logging:commons-logging:jar:1.0:compile(removed
> -
> > > nearer found: 1.0.4)
> > ...
> > > However, the version of commons-logging that appears in my classpath
> for
> > > test is 1.0.4, NOT 1.1 as it appears that it ought to be.
> Additionally,
> > this
> > > means that avalon-framework is not present in my surefire test
> > classpath,
> > > causing tests to break.
> >
> > If "removed - nearer found: 1.0.4" is the last thing you see, then
> > that's the version Maven has chosen.
> >
> > The list archives contain plenty of discussion about Maven 2.0.4's
> > approach to transitive dependency resolution, especially when
> > <dependencyManagement> is in use. It's something that has been
> > improved for the next release.
> >
> > The usual fix is the explicitly declare the dependency version you
> > want, in the project pom where the problem is occurring.
> >
> > If that doesn't help, we need to see the pom and the full output of mvn
> > -X.
> >
> > --
> > Wendy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com
Re: surefire transitive classpath bug ?
Posted by Nigel Magnay <ni...@gmail.com>.
But the -X shows 2 lines for commons-logging, both claiming to be selected
for compile:
[DEBUG] commons-logging:commons-logging:jar:1.1:compile (selected for
compile)
[DEBUG] commons-logging:commons-logging:jar:1.0.4:compile (selected
for compile)
Though actually the compile works, it's the tests that don't. This is
actually not because of commons-logging, but one of the dependencies that
1.1 includes, but 1.0.4 does not.
I also have another problem elsewhere where tests *randomly* fail, because
commons-lang isn't on the test classpath, even though it's the very first
jar file specified in the POM!
This leads me to suspect that the dependencies are being stuffed in a
hashmap somewhere, and dependent upon the phase of the moon, one particular
version 'wins'. This has basically destroyed our ability to do CI builds,
and developers must 'mvn install - if tests fail, rinse, repeat'.
I'll file a JIRA with full -X output; I've been testing with surefire
2.3-SNAPSHOT which may be better. As is always the case with these things,
turning on -X tends to make it work ;-S
On 08/12/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 12/8/06, Nigel Magnay <ni...@gmail.com> wrote:
>
> > I think this is a bug in surefire. If I run my project with mvn -X I see
> in
> > the output :
> ...
> > [DEBUG] commons-logging:commons-logging:jar:1.0:compile(removed -
> > nearer found: 1.0.4)
> ...
> > However, the version of commons-logging that appears in my classpath for
> > test is 1.0.4, NOT 1.1 as it appears that it ought to be. Additionally,
> this
> > means that avalon-framework is not present in my surefire test
> classpath,
> > causing tests to break.
>
> If "removed - nearer found: 1.0.4" is the last thing you see, then
> that's the version Maven has chosen.
>
> The list archives contain plenty of discussion about Maven 2.0.4's
> approach to transitive dependency resolution, especially when
> <dependencyManagement> is in use. It's something that has been
> improved for the next release.
>
> The usual fix is the explicitly declare the dependency version you
> want, in the project pom where the problem is occurring.
>
> If that doesn't help, we need to see the pom and the full output of mvn
> -X.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: surefire transitive classpath bug ?
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/8/06, Nigel Magnay <ni...@gmail.com> wrote:
> I think this is a bug in surefire. If I run my project with mvn -X I see in
> the output :
...
> [DEBUG] commons-logging:commons-logging:jar:1.0:compile (removed -
> nearer found: 1.0.4)
...
> However, the version of commons-logging that appears in my classpath for
> test is 1.0.4, NOT 1.1 as it appears that it ought to be. Additionally, this
> means that avalon-framework is not present in my surefire test classpath,
> causing tests to break.
If "removed - nearer found: 1.0.4" is the last thing you see, then
that's the version Maven has chosen.
The list archives contain plenty of discussion about Maven 2.0.4's
approach to transitive dependency resolution, especially when
<dependencyManagement> is in use. It's something that has been
improved for the next release.
The usual fix is the explicitly declare the dependency version you
want, in the project pom where the problem is occurring.
If that doesn't help, we need to see the pom and the full output of mvn -X.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org