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 <[EMAIL PROTECTED]> 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 <[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] > >
-- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com