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
>

Reply via email to