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 <[EMAIL PROTECTED]> wrote:
On 12/8/06, Nigel Magnay <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
