Hi Wendy, > These poms are incorrect -- servlet-api shouldn't be in compile scope. I see.
> Another way that will work is to declare the servlet-api dependency in > your own project and properly mark it 'provided'. Since Maven uses > the "closest" definition for each artifact, that one will win. [1]If I set both of servlet-api-2.3(in commons-logging-1.1.pom) and servlet-api-2.4(in my own declared pom) to provided scope. Then run "mvn package", none of them would be putted into WEB-INF/lib; run "mvn eclipse:eclipse", none of them would be in .classpath file. That 's not my want. I wish servlet-api-2.4.jar in .classpath file. [2]If I set both of them to compile scope. Then run "mvn package", only servlet-api-2.3.jar would be puutted into WEB-INF/lib; run "mvn eclipse:eclipse", only servlet-api-2.3.jar in .classpath file. [3]If I set servlet-api-2.4.jar to compile scope, and modify commons-loggin-1.1.pom and set servlet-api-2.3.jar to provided scope. Then run "mvn package", none of servlet-api would be putted in WEB-INF/lib; run "mvn eclipse:eclipse", none would be in .classpath. According the three cases, it really means that Maven uses the "closest" scope for one dependency. But what about version? Maven how to "pick up" dependencies? What's the regular for choosing version? Lower or higher? According to the my casees above, it seems that Maven likes the lower one? a cup of Java, cheers! Sha Jiang Wendy Smoak-3 wrote: > > On 11/25/06, jiangshachina <[EMAIL PROTECTED]> wrote: > >> For example, on servlet-api artiface. >> I declare servlet-api-2.4.jar in others POM, but commons-loggin(in Apache >> POM) has transitive dependency servlet-api-2.3.jar. Both of them are >> compile >> scope. > > These poms are incorrect -- servlet-api shouldn't be in compile scope. > >> When I run "mvn package" for the Web project, I found that >> servlet-api-2.3.jar, but servlet-api-2.4.jar, in WEB-INF/lib. >> If I modified POM of commons-loggin, and declared servlet-api-2.3.jar as >> provided dependency, then none of them would be put into WEB-INF/lib! > > Modifying public poms is one way to do it, and can work if you have > complete control of an internal corporate repository. > > A better way to fix this is to add <exclusions> to the dependencies > that are causing the problem, then go back to the project in question > and ask them to fix it in the next release. Quite often the project > causing the problem is not using m2 to build, and the developers don't > understand what happens when they leave everything in compile scope. > > Another way that will work is to declare the servlet-api dependency in > your own project and properly mark it 'provided'. Since Maven uses > the "closest" definition for each artifact, that one will win. > > -- > Wendy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Don%27t-add-dependency--tf2677027s177.html#a7545093 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
