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 <[email protected]>
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ć <[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
