After inheritance, the war dependency tree looks like this: foo.bar:b:war:0.0.1-SNAPSHOT +- org.apache.velocity:velocity:jar:1.6.2:test \- foo.bar:a:jar:0.0.1-SNAPSHOT:compile +- org.apache.velocity:velocity:jar:1.6.2:test \- org.apache.velocity:velocity:jar:1.6.2:compile
So the resolved scope for velocity is test since the war pom takes precedence over any transitive dependencies. I agree that this is not the best behaviour. Just one of the many dependency resolution problems that I hope will be solved with Mercury :) Mark 2009/5/6 Stevo Slavić <[email protected]>: > Warning (dependency:resolve printed) that broader scope has been overridden > doesn't even print when one packages project... > > Regards, > Stevo. > > 2009/5/6 Stevo Slavić <[email protected]> > >> Thanks Nick for quick reply! >> >> Shouldn't broader scope win over narrower one, at least in this specific >> scenario? >> >> Regards, >> Stevo. >> >> >> On Wed, May 6, 2009 at 11:40 AM, Nick Stolwijk >> <[email protected]>wrote: >> >>> 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] >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
