This is really a symptom of the nearest-wins mentality of Maven 2, since scopes specified in the current POM take precedence over their transitive values, and not widened as expected. AFAIK Mercury will replace nearest-wins version conflict resolution with a more usable highest-wins, so I was hoping that it'd also take a similar approach with scope conflicts and always widen them, irrespective of where they are defined. Perhaps Oleg could clarify?
Cheers, Mark 2009/5/7 Brian Fox <bri...@infinity.nu>: > I think this will help you understand it better: > Think of inheritance as including the contents of the parents inside your > own pom. (obviously merging occurs). I used to be a C programmer so I refer > to this as #include-ing the contents. > > Therefore the result of inheritance is that it updates your local pom. > Things declared in your local pom always superceede transitive, thus the > behavior seems to be correct. > > So to restate the problem, you are using in one module a jar LIB that you > only need in your tests, but transitively you depend on something which > needs LIB at runtime and thus it should be packed into your war? If so, just > flip your dependency to a compile scope since this is also included in test > classpaths. This is generally an unusual scenario, I don't think it's solved > yet with Mercury. > > My suggestion is to provide a sample project as an IT and write up an issue > for this. > > On Wed, May 6, 2009 at 5:29 AM, Stevo Slavić <ssla...@gmail.com> wrote: > >> Hello Maven users, >> >> If a parent module (e.g. P) of a multi module project defines a test scope >> dependency to some library (e.g. library "LIB"), and if one of projects's >> child modules which inherit P (e.g. jar module A) defines compile scope >> dependency to the same (LIB) library, and if some other child module which >> also inherits P (e.g. war module B) defines compile scope dependency on >> module A, then (at least when using maven 2.1.0) library LIB does not get >> included in war of module B. It seems that scope (in this example test >> scope) of inherited dependency wins over scope (in this example compile >> scope) of transitive dependency. >> >> This looks like a bug to me (maybe just in maven-war-plugin:2.1-beta-1, or >> maven-dependency-plugin:2.1) - even though module B (through inheritance) >> defines LIB as test scope dependency but on the other hand it's dependency >> defines same LIB as compile scope dependency so LIB should be included in >> module B war. Currently a workaround is to explicitly define compile time >> dependency to LIB in module B, even though it doesn't make direct use of the >> LIB. As subject states, maybe I've misunderstood the dependency resolution >> mechanism. >> >> Attached is example project which demonstrates the issue. >> >> Regards, >> Stevo. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
