When I run mvn dependency:resolve the output explains something more.
(Ran it with debug on)
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - foo.bar:b:war:0.0.1-SNAPSHOT
[INFO] task-segment: [dependency:resolve]
[INFO] ------------------------------------------------------------------------
[DEBUG] foo.bar:b:war:0.0.1-SNAPSHOT (selected for null)
[DEBUG] foo.bar:a:jar:0.0.1-SNAPSHOT:compile (selected for compile)
[DEBUG] org.apache.velocity:velocity:jar:1.6.2:compile (selected
for compile)
[DEBUG] commons-collections:commons-collections:jar:3.2.1:compile
(selected for compile)
[DEBUG] commons-lang:commons-lang:jar:2.4:compile (selected for
compile)
[DEBUG] oro:oro:jar:2.0.8:compile (selected for compile)
[DEBUG] org.apache.velocity:velocity:jar:1.6.2:test (not setting
scope to: compile; local scope test wins)
[WARNING]
Artifact org.apache.velocity:velocity:jar:1.6.2:test retains
local scope 'test' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or
remove the local scope.
[DEBUG] org.apache.velocity:velocity:jar:1.6.2:test (selected for
test)
[DEBUG] commons-collections:commons-collections:jar:3.2.1:test
(selected for test)
[DEBUG] commons-lang:commons-lang:jar:2.4:test (selected for test)
[DEBUG] oro:oro:jar:2.0.8:test (selected for test)
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Wed, May 6, 2009 at 11:37 AM, Nick Stolwijk <nick.stolw...@gmail.com> wrote:
> When I run your example with mvn dependency:tree this is what I get:
>
> [INFO] [dependency:tree]
> [INFO] foo.bar:foo-bar-parent:pom:0.0.1-SNAPSHOT
> [INFO] \- org.apache.velocity:velocity:jar:1.6.2:test
> [INFO] +- commons-collections:commons-collections:jar:3.2.1:test
> [INFO] +- commons-lang:commons-lang:jar:2.4:test
> [INFO] \- oro:oro:jar:2.0.8:test
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Unnamed - foo.bar:a:jar:0.0.1-SNAPSHOT
> [INFO] task-segment: [dependency:tree]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] [dependency:tree]
> [INFO] foo.bar:a:jar:0.0.1-SNAPSHOT
> [INFO] \- org.apache.velocity:velocity:jar:1.6.2:compile
> [INFO] +- commons-collections:commons-collections:jar:3.2.1:compile
> [INFO] +- commons-lang:commons-lang:jar:2.4:compile
> [INFO] \- oro:oro:jar:2.0.8:compile
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Unnamed - foo.bar:b:war:0.0.1-SNAPSHOT
> [INFO] task-segment: [dependency:tree]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] [dependency:tree]
> [INFO] foo.bar:b:war:0.0.1-SNAPSHOT
> [INFO] +- foo.bar:a:jar:0.0.1-SNAPSHOT:compile
> [INFO] \- org.apache.velocity:velocity:jar:1.6.2:test (scope not
> updated to compile)
> [INFO] +- commons-collections:commons-collections:jar:3.2.1:test
> [INFO] +- commons-lang:commons-lang:jar:2.4:test
> [INFO] \- oro:oro:jar:2.0.8:test
>
> Mind the "scope not updated to compile", so Maven sees something
> strange. I don't know whether this is a bug or a feature ;) or what
> the rationale is behind it.
>
> Can someone explain?
>
> With regards,
>
> Nick Stolwijk
> ~Java Developer~
>
> Iprofs BV.
> Claus Sluterweg 125
> 2012 WS Haarlem
> www.iprofs.nl
>
>
>
> On Wed, May 6, 2009 at 11: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
