>As an example of the kinds of problems that "high-level automation" >can bring....Our project needed to use some specific libraries that >came with the XXX software package. I figured out the Maven incantation >to correctly 'install' these libraries to our local repository using one >of the Maven FAQ pages. Soon after that, however, I found myself >debugging a problem in the XXX library source code. I'm looking at the source >code and saying "this error couldn't possibly happen given this >source code". Sure enough, Maven had downloaded some other >version of the library without our knowledge, even though our >POM files specified the exact version I had loaded by hand. Now, I assume, >that this kind of thing is controllable and preventable, if you know >which POM file option or configuration flag to use but, of course, >that's a big learning curve in itself.
I ran into this problem before. It is related to Maven's support of transitive dependencies where you only need to declare the direct dependencies in your POM and maven will go and download all of you transitive dependencies. In your case what happened is that the older version of the library was a transitive dependency of some other direct dependency in your pom so it was downloaded with compile scope. The solution is to use the exclude element when downloading your direct dependency to avoid downloading a transitive dependency you dont want. Another thing you might notice when building war files with maven 2 is that the generated war file is always bigger than maven 1. It is again related to maven's transitive dependencies and you will have to make some changes in your pom in order not to included those unneeded libraries in your war file. Bashar --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
