You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stevo Slavić <ss...@gmail.com> on 2009/05/06 11:29:26 UTC
Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
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.
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Tobias Gierke <to...@code-sourcery.de>.
Hi,
> 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
> :)
>
Just as a side-note (because I was recently bitten by this one too) :
The same happens when using the assembly-plugin to include dependencies
with <dependencySet/>.
Tobias
> Mark
>
> 2009/5/6 Stevo Slavić <ss...@gmail.com>:
>
>> 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ć <ss...@gmail.com>
>>
>>
>>> 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 <ni...@gmail.com>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 <ni...@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ć <ss...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Mark Hobson <ma...@gmail.com>.
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ć <ss...@gmail.com>:
> 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ć <ss...@gmail.com>
>
>> 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 <ni...@gmail.com>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 <ni...@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ć <ss...@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-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: users-help@maven.apache.org
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stevo Slavić <ss...@gmail.com>.
Greater problem here is that tests would run fine (except functional tests,
if there are any, that would actually deploy/run war), and one could
discover dependency is missing only at runtime...
Regards,
Stevo.
2009/5/6 Stevo Slavić <ss...@gmail.com>
> 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ć <ss...@gmail.com>
>
> 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 <ni...@gmail.com>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 <ni...@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ć <ss...@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-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: users-help@maven.apache.org
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stevo Slavić <ss...@gmail.com>.
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ć <ss...@gmail.com>
> 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 <ni...@gmail.com>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 <ni...@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ć <ss...@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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stevo Slavić <ss...@gmail.com>.
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 <ni...@gmail.com>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 <ni...@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ć <ss...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Nick Stolwijk <ni...@gmail.com>.
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 <ni...@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ć <ss...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Nick Stolwijk <ni...@gmail.com>.
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ć <ss...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Mark Hobson <ma...@gmail.com>.
2009/5/8 Jörg Schaible <jo...@gmx.de>:
> This would be the show stopper for me for ever using Mercury. If I narrow
> the scope in the local POM it is done *because I want it so*, e.g.
> preventing compile time deps to a specific implementation that's hidden
> behind an interface.
This should be done in dependency management though, not as a direct
dependency. At least it could when MNG-3695 is fixed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Mark Hobson <ma...@gmail.com>.
2009/5/8 Jörg Schaible <jo...@gmx.de>:
>> E.g. if project P has test scoped dependency to a LIB1, and compile scoped
>> dependency to LIB2, while LIB2 has compile scope dependency to LIB1,
>> currently project P's war will wrongly end up without LIB1 included.
>
> This is the whole point: This is not wrong, Maven did it right! Actually we
> use scope narrowing to trim down dependencies that are not needed/only
> needed for test or provided by the container.
I don't follow that logic, adding a test dependency shouldn't affect
the compile classpath. What's a use case for scope-narrowing? I've
had scopes being narrowed before due to bugs (such as MNG-2686) and
they're pretty hard to track down in large dependency trees.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stevo Slavić <ss...@gmail.com>.
Just created http://jira.codehaus.org/browse/MNG-4156
Regards,
Stevo.
On Mon, May 11, 2009 at 6:40 PM, Mark Hobson <ma...@gmail.com> wrote:
> 2009/5/11 Brian Fox <br...@infinity.nu>:
> > At face value the logic seems to make sense, but I haven't thought
> through
> > all the ramifications. I thought Mark Hobson mentioned some cases where
> the
> > opposite was desired. At this point your best bet is to prepare a
> proposal
> > on http://docs.codehaus.org/display/MAVENUSER/User+Proposals with an
> > associated Jira and then start building some consensus around the
> changes.
> >
> > Work in this area for 3.x is nearing so now's a good time to create the
> > proposal.
>
> I'm all in favour of local test scope not overriding transitive
> compile scope. I've just this second been bitten by this again and
> had to mangle the pom to workaround it. Local dependencies shouldn't
> have any higher precedence that transitive ones; if you want to force
> a dependency's version and/or scope, then dependency management should
> be used for this purpose.
>
> The compile/test runtime/provided scope separation sounds interesting
> but I'd need some time to think it through.
>
> Let's at least get this first issue in JIRA before it gets lost, has
> anything been raised?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Mark Hobson <ma...@gmail.com>.
2009/5/11 Brian Fox <br...@infinity.nu>:
> At face value the logic seems to make sense, but I haven't thought through
> all the ramifications. I thought Mark Hobson mentioned some cases where the
> opposite was desired. At this point your best bet is to prepare a proposal
> on http://docs.codehaus.org/display/MAVENUSER/User+Proposals with an
> associated Jira and then start building some consensus around the changes.
>
> Work in this area for 3.x is nearing so now's a good time to create the
> proposal.
I'm all in favour of local test scope not overriding transitive
compile scope. I've just this second been bitten by this again and
had to mangle the pom to workaround it. Local dependencies shouldn't
have any higher precedence that transitive ones; if you want to force
a dependency's version and/or scope, then dependency management should
be used for this purpose.
The compile/test runtime/provided scope separation sounds interesting
but I'd need some time to think it through.
Let's at least get this first issue in JIRA before it gets lost, has
anything been raised?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stephen Connolly <st...@gmail.com>.
2009/5/11 Todd Thiessen <th...@nortel.com>
> > you may have a valid reason for so doing, but maven is no
> > medium and cannot ask a higher plain what you wanted to do.
>
> It doesn't need to. Maven has all the information. If a transitive
> dependency has compile scope it should never get demoted to test scope.
>
> However, you do want it to get demoted to runtime/provided scope.
>
Which leads me to suspect that you should be using exclusions
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stevo Slavić <ss...@gmail.com>.
One can package, install and deploy such a war, no warning related to this
issue will get printed.
Regards,
Stevo.
On Sun, May 10, 2009 at 8:57 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> IIRC maven warns you that you have changed a dependency from compile scope
> to test scope.
>
> you may have a valid reason for so doing, but maven is no medium and cannot
> ask a higher plain what you wanted to do. if a warning is not good enough,
> tough
>
> Sent from my [rhymes with myPod] ;-)
>
> On 10 May 2009, at 18:01, Stevo Slavić <ss...@gmail.com> wrote:
>
> "Just because that's the way things are doesn't mean that's how they
>> should
>> be.", said a character in the movie "Australia".
>>
>> In this particular scenario, local test scoped dependency vs compile scope
>> transitive dependency, it's my opinion that current strategy is wrong.
>> Local
>> test scoped dependencies shouldn't by default override compile scoped
>> transitive dependencies. If one wanted to exclude transitive compile
>> scoped
>> dependency and have it available only in test scope, it would be more
>> natural (for me at least) to require user to specify appropriate excludes
>> section on a dependency that brought transitive dependency with it. Again,
>> just in this particular case, requiring user to explicitly specify
>> excludes
>> section would more clearly state/document the intention, while currently
>> build tool silently makes a wrong decision (maybe there are times this
>> decision is correct, but IMO it correct in far less cases than it is
>> wrong).
>>
>> Regards,
>> Stevo.
>>
>> 2009/5/10 Brian Fox <br...@infinity.nu>
>>
>> By local I mean the pom currently being built. Stuff defined here always
>>> overrides dependencies and transitive dependencies.
>>>
>>> On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić <ss...@gmail.com> wrote:
>>>
>>> Is there any reason why would local win in this particular case?
>>>>
>>>> Regards,
>>>> Stevo.
>>>>
>>>> On Sun, May 10, 2009 at 5:26 AM, Brian Fox <br...@infinity.nu> wrote:
>>>>
>>>> On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen <th...@nortel.com>
>>>>> wrote:
>>>>>
>>>>> Override the dependency defined in the POM, as Steve outline in his
>>>>>> earlier response. Let me quote his explanation for ease of reference:
>>>>>>
>>>>>> "E.g. if project P has test scoped dependency to a LIB1, and compile
>>>>>> scoped dependency to LIB2, while LIB2 has compile scope dependency to
>>>>>> LIB1, currently project P's war will wrongly end up without LIB1
>>>>>> included. In P one expects LIB1 to be available for testing, but that
>>>>>> shouldn't affect availability of LIB1 as compile scoped transitive
>>>>>> dependency, it should be the other way round, in this case scope of
>>>>>> declared test scoped dependency should be broadened."
>>>>>>
>>>>>> I used the term "override" to descibe the situation when project P
>>>>>> should have LIB1 defined as a compile dependency, when the POM
>>>>>>
>>>>> actually
>>>
>>>> defines it as test. But it should should only override for test
>>>>>> dependencies, not for provided or runtime.
>>>>>>
>>>>>>
>>>>> The local pom always wins. Placing additional semantics on how things
>>>>>
>>>> merge
>>>>
>>>>> is troublesome. I'm sure we can think of scenarios where widening is
>>>>>
>>>> not
>>>
>>>> the
>>>>> right thing to do. In either case you must have the ability to resolve
>>>>>
>>>> this
>>>>
>>>>> yourself if it doesn't do the right thing...and the way to do that is
>>>>>
>>>> to
>>>
>>>> put
>>>>> what you want in the local pom.
>>>>>
>>>>>
>>>>>
>>>>>> As for your "lost me" comment I am not sure what you would like
>>>>>> explained. Scope basically has multiple meanings. Compile/test are
>>>>>>
>>>>> both
>>>>
>>>>> related to requiring a dependency for compilation; runtime/provided
>>>>>>
>>>>> are
>>>
>>>> both related to requiring a dependency only at runtime. These
>>>>>>
>>>>> multiple
>>>
>>>> meanings are not suited to a single variable.
>>>>>>
>>>>>>
>>>>> Are there many cases where you want something for compilation that
>>>>>
>>>> isn't
>>>
>>>> needed at runtime? I don't see them as being separate.
>>>>>
>>>>>
>>>>>
>>>>>> ---
>>>>>> Todd Thiessen
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Todd Thiessen <th...@nortel.com>.
> you may have a valid reason for so doing, but maven is no
> medium and cannot ask a higher plain what you wanted to do.
It doesn't need to. Maven has all the information. If a transitive
dependency has compile scope it should never get demoted to test scope.
However, you do want it to get demoted to runtime/provided scope.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Stephen Connolly <st...@gmail.com>.
IIRC maven warns you that you have changed a dependency from compile
scope to test scope.
you may have a valid reason for so doing, but maven is no medium and
cannot ask a higher plain what you wanted to do. if a warning is not
good enough, tough
Sent from my [rhymes with myPod] ;-)
On 10 May 2009, at 18:01, Stevo Slavić <ss...@gmail.com> wrote:
> "Just because that's the way things are doesn't mean that's how they
> should
> be.", said a character in the movie "Australia".
>
> In this particular scenario, local test scoped dependency vs compile
> scope
> transitive dependency, it's my opinion that current strategy is
> wrong. Local
> test scoped dependencies shouldn't by default override compile scoped
> transitive dependencies. If one wanted to exclude transitive compile
> scoped
> dependency and have it available only in test scope, it would be more
> natural (for me at least) to require user to specify appropriate
> excludes
> section on a dependency that brought transitive dependency with it.
> Again,
> just in this particular case, requiring user to explicitly specify
> excludes
> section would more clearly state/document the intention, while
> currently
> build tool silently makes a wrong decision (maybe there are times this
> decision is correct, but IMO it correct in far less cases than it is
> wrong).
>
> Regards,
> Stevo.
>
> 2009/5/10 Brian Fox <br...@infinity.nu>
>
>> By local I mean the pom currently being built. Stuff defined here
>> always
>> overrides dependencies and transitive dependencies.
>>
>> On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić <ss...@gmail.com>
>> wrote:
>>
>>> Is there any reason why would local win in this particular case?
>>>
>>> Regards,
>>> Stevo.
>>>
>>> On Sun, May 10, 2009 at 5:26 AM, Brian Fox <br...@infinity.nu>
>>> wrote:
>>>
>>>> On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen
>>>> <th...@nortel.com>
>>>> wrote:
>>>>
>>>>> Override the dependency defined in the POM, as Steve outline in
>>>>> his
>>>>> earlier response. Let me quote his explanation for ease of
>>>>> reference:
>>>>>
>>>>> "E.g. if project P has test scoped dependency to a LIB1, and
>>>>> compile
>>>>> scoped dependency to LIB2, while LIB2 has compile scope
>>>>> dependency to
>>>>> LIB1, currently project P's war will wrongly end up without LIB1
>>>>> included. In P one expects LIB1 to be available for testing, but
>>>>> that
>>>>> shouldn't affect availability of LIB1 as compile scoped transitive
>>>>> dependency, it should be the other way round, in this case scope
>>>>> of
>>>>> declared test scoped dependency should be broadened."
>>>>>
>>>>> I used the term "override" to descibe the situation when project P
>>>>> should have LIB1 defined as a compile dependency, when the POM
>> actually
>>>>> defines it as test. But it should should only override for test
>>>>> dependencies, not for provided or runtime.
>>>>>
>>>>
>>>> The local pom always wins. Placing additional semantics on how
>>>> things
>>> merge
>>>> is troublesome. I'm sure we can think of scenarios where widening
>>>> is
>> not
>>>> the
>>>> right thing to do. In either case you must have the ability to
>>>> resolve
>>> this
>>>> yourself if it doesn't do the right thing...and the way to do
>>>> that is
>> to
>>>> put
>>>> what you want in the local pom.
>>>>
>>>>
>>>>>
>>>>> As for your "lost me" comment I am not sure what you would like
>>>>> explained. Scope basically has multiple meanings. Compile/test
>>>>> are
>>> both
>>>>> related to requiring a dependency for compilation; runtime/
>>>>> provided
>> are
>>>>> both related to requiring a dependency only at runtime. These
>> multiple
>>>>> meanings are not suited to a single variable.
>>>>>
>>>>
>>>> Are there many cases where you want something for compilation that
>> isn't
>>>> needed at runtime? I don't see them as being separate.
>>>>
>>>>
>>>>>
>>>>> ---
>>>>> Todd Thiessen
>>>>>
>>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Brian Fox <br...@infinity.nu>.
2009/5/10 Stevo Slavić <ss...@gmail.com>
> "Just because that's the way things are doesn't mean that's how they should
> be.", said a character in the movie "Australia".
>
I dig that.
>
> In this particular scenario, local test scoped dependency vs compile scope
> transitive dependency, it's my opinion that current strategy is wrong.
> Local
> test scoped dependencies shouldn't by default override compile scoped
> transitive dependencies. If one wanted to exclude transitive compile scoped
> dependency and have it available only in test scope, it would be more
> natural (for me at least) to require user to specify appropriate excludes
> section on a dependency that brought transitive dependency with it. Again,
> just in this particular case, requiring user to explicitly specify excludes
> section would more clearly state/document the intention, while currently
> build tool silently makes a wrong decision (maybe there are times this
> decision is correct, but IMO it correct in far less cases than it is
> wrong).
>
At face value the logic seems to make sense, but I haven't thought through
all the ramifications. I thought Mark Hobson mentioned some cases where the
opposite was desired. At this point your best bet is to prepare a proposal
on http://docs.codehaus.org/display/MAVENUSER/User+Proposals with an
associated Jira and then start building some consensus around the changes.
Work in this area for 3.x is nearing so now's a good time to create the
proposal.
>
> Regards,
> Stevo.
>
> 2009/5/10 Brian Fox <br...@infinity.nu>
>
> > By local I mean the pom currently being built. Stuff defined here always
> > overrides dependencies and transitive dependencies.
> >
> > On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić <ss...@gmail.com> wrote:
> >
> > > Is there any reason why would local win in this particular case?
> > >
> > > Regards,
> > > Stevo.
> > >
> > > On Sun, May 10, 2009 at 5:26 AM, Brian Fox <br...@infinity.nu> wrote:
> > >
> > > > On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen <th...@nortel.com>
> > > > wrote:
> > > >
> > > > > Override the dependency defined in the POM, as Steve outline in his
> > > > > earlier response. Let me quote his explanation for ease of
> reference:
> > > > >
> > > > > "E.g. if project P has test scoped dependency to a LIB1, and
> compile
> > > > > scoped dependency to LIB2, while LIB2 has compile scope dependency
> to
> > > > > LIB1, currently project P's war will wrongly end up without LIB1
> > > > > included. In P one expects LIB1 to be available for testing, but
> that
> > > > > shouldn't affect availability of LIB1 as compile scoped transitive
> > > > > dependency, it should be the other way round, in this case scope of
> > > > > declared test scoped dependency should be broadened."
> > > > >
> > > > > I used the term "override" to descibe the situation when project P
> > > > > should have LIB1 defined as a compile dependency, when the POM
> > actually
> > > > > defines it as test. But it should should only override for test
> > > > > dependencies, not for provided or runtime.
> > > > >
> > > >
> > > > The local pom always wins. Placing additional semantics on how things
> > > merge
> > > > is troublesome. I'm sure we can think of scenarios where widening is
> > not
> > > > the
> > > > right thing to do. In either case you must have the ability to
> resolve
> > > this
> > > > yourself if it doesn't do the right thing...and the way to do that is
> > to
> > > > put
> > > > what you want in the local pom.
> > > >
> > > >
> > > > >
> > > > > As for your "lost me" comment I am not sure what you would like
> > > > > explained. Scope basically has multiple meanings. Compile/test are
> > > both
> > > > > related to requiring a dependency for compilation; runtime/provided
> > are
> > > > > both related to requiring a dependency only at runtime. These
> > multiple
> > > > > meanings are not suited to a single variable.
> > > > >
> > > >
> > > > Are there many cases where you want something for compilation that
> > isn't
> > > > needed at runtime? I don't see them as being separate.
> > > >
> > > >
> > > > >
> > > > > ---
> > > > > Todd Thiessen
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Stephen Connolly <st...@gmail.com>.
Sent from my [rhymes with myPod] ;-)
On 10 May 2009, at 18:01, Stevo Slavić <ss...@gmail.com> wrote:
> "Just because that's the way things are doesn't mean that's how they
> should
> be.", said a character in the movie "Australia".
>
> In this particular scenario, local test scoped dependency vs compile
> scope
> transitive dependency, it's my opinion that current strategy is
> wrong. Local
> test scoped dependencies shouldn't by default override compile scoped
> transitive dependencies. If one wanted to exclude transitive compile
> scoped
> dependency and have it available only in test scope, it would be more
> natural (for me at least) to require user to specify appropriate
> excludes
> section on a dependency that brought transitive dependency with it.
> Again,
> just in this particular case, requiring user to explicitly specify
> excludes
> section would more clearly state/document the intention, while
> currently
> build tool silently makes a wrong decision (maybe there are times this
> decision is correct, but IMO it correct in far less cases than it is
> wrong).
>
> Regards,
> Stevo.
>
> 2009/5/10 Brian Fox <br...@infinity.nu>
>
>> By local I mean the pom currently being built. Stuff defined here
>> always
>> overrides dependencies and transitive dependencies.
>>
>> On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić <ss...@gmail.com>
>> wrote:
>>
>>> Is there any reason why would local win in this particular case?
>>>
>>> Regards,
>>> Stevo.
>>>
>>> On Sun, May 10, 2009 at 5:26 AM, Brian Fox <br...@infinity.nu>
>>> wrote:
>>>
>>>> On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen
>>>> <th...@nortel.com>
>>>> wrote:
>>>>
>>>>> Override the dependency defined in the POM, as Steve outline in
>>>>> his
>>>>> earlier response. Let me quote his explanation for ease of
>>>>> reference:
>>>>>
>>>>> "E.g. if project P has test scoped dependency to a LIB1, and
>>>>> compile
>>>>> scoped dependency to LIB2, while LIB2 has compile scope
>>>>> dependency to
>>>>> LIB1, currently project P's war will wrongly end up without LIB1
>>>>> included. In P one expects LIB1 to be available for testing, but
>>>>> that
>>>>> shouldn't affect availability of LIB1 as compile scoped transitive
>>>>> dependency, it should be the other way round, in this case scope
>>>>> of
>>>>> declared test scoped dependency should be broadened."
>>>>>
>>>>> I used the term "override" to descibe the situation when project P
>>>>> should have LIB1 defined as a compile dependency, when the POM
>> actually
>>>>> defines it as test. But it should should only override for test
>>>>> dependencies, not for provided or runtime.
>>>>>
>>>>
>>>> The local pom always wins. Placing additional semantics on how
>>>> things
>>> merge
>>>> is troublesome. I'm sure we can think of scenarios where widening
>>>> is
>> not
>>>> the
>>>> right thing to do. In either case you must have the ability to
>>>> resolve
>>> this
>>>> yourself if it doesn't do the right thing...and the way to do
>>>> that is
>> to
>>>> put
>>>> what you want in the local pom.
>>>>
>>>>
>>>>>
>>>>> As for your "lost me" comment I am not sure what you would like
>>>>> explained. Scope basically has multiple meanings. Compile/test
>>>>> are
>>> both
>>>>> related to requiring a dependency for compilation; runtime/
>>>>> provided
>> are
>>>>> both related to requiring a dependency only at runtime. These
>> multiple
>>>>> meanings are not suited to a single variable.
>>>>>
>>>>
>>>> Are there many cases where you want something for compilation that
>> isn't
>>>> needed at runtime? I don't see them as being separate.
>>>>
>>>>
>>>>>
>>>>> ---
>>>>> Todd Thiessen
>>>>>
>>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stevo Slavić <ss...@gmail.com>.
"Just because that's the way things are doesn't mean that's how they should
be.", said a character in the movie "Australia".
In this particular scenario, local test scoped dependency vs compile scope
transitive dependency, it's my opinion that current strategy is wrong. Local
test scoped dependencies shouldn't by default override compile scoped
transitive dependencies. If one wanted to exclude transitive compile scoped
dependency and have it available only in test scope, it would be more
natural (for me at least) to require user to specify appropriate excludes
section on a dependency that brought transitive dependency with it. Again,
just in this particular case, requiring user to explicitly specify excludes
section would more clearly state/document the intention, while currently
build tool silently makes a wrong decision (maybe there are times this
decision is correct, but IMO it correct in far less cases than it is wrong).
Regards,
Stevo.
2009/5/10 Brian Fox <br...@infinity.nu>
> By local I mean the pom currently being built. Stuff defined here always
> overrides dependencies and transitive dependencies.
>
> On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić <ss...@gmail.com> wrote:
>
> > Is there any reason why would local win in this particular case?
> >
> > Regards,
> > Stevo.
> >
> > On Sun, May 10, 2009 at 5:26 AM, Brian Fox <br...@infinity.nu> wrote:
> >
> > > On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen <th...@nortel.com>
> > > wrote:
> > >
> > > > Override the dependency defined in the POM, as Steve outline in his
> > > > earlier response. Let me quote his explanation for ease of reference:
> > > >
> > > > "E.g. if project P has test scoped dependency to a LIB1, and compile
> > > > scoped dependency to LIB2, while LIB2 has compile scope dependency to
> > > > LIB1, currently project P's war will wrongly end up without LIB1
> > > > included. In P one expects LIB1 to be available for testing, but that
> > > > shouldn't affect availability of LIB1 as compile scoped transitive
> > > > dependency, it should be the other way round, in this case scope of
> > > > declared test scoped dependency should be broadened."
> > > >
> > > > I used the term "override" to descibe the situation when project P
> > > > should have LIB1 defined as a compile dependency, when the POM
> actually
> > > > defines it as test. But it should should only override for test
> > > > dependencies, not for provided or runtime.
> > > >
> > >
> > > The local pom always wins. Placing additional semantics on how things
> > merge
> > > is troublesome. I'm sure we can think of scenarios where widening is
> not
> > > the
> > > right thing to do. In either case you must have the ability to resolve
> > this
> > > yourself if it doesn't do the right thing...and the way to do that is
> to
> > > put
> > > what you want in the local pom.
> > >
> > >
> > > >
> > > > As for your "lost me" comment I am not sure what you would like
> > > > explained. Scope basically has multiple meanings. Compile/test are
> > both
> > > > related to requiring a dependency for compilation; runtime/provided
> are
> > > > both related to requiring a dependency only at runtime. These
> multiple
> > > > meanings are not suited to a single variable.
> > > >
> > >
> > > Are there many cases where you want something for compilation that
> isn't
> > > needed at runtime? I don't see them as being separate.
> > >
> > >
> > > >
> > > > ---
> > > > Todd Thiessen
> > > >
> > > >
> > >
> >
>
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Brian Fox <br...@infinity.nu>.
By local I mean the pom currently being built. Stuff defined here always
overrides dependencies and transitive dependencies.
On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić <ss...@gmail.com> wrote:
> Is there any reason why would local win in this particular case?
>
> Regards,
> Stevo.
>
> On Sun, May 10, 2009 at 5:26 AM, Brian Fox <br...@infinity.nu> wrote:
>
> > On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen <th...@nortel.com>
> > wrote:
> >
> > > Override the dependency defined in the POM, as Steve outline in his
> > > earlier response. Let me quote his explanation for ease of reference:
> > >
> > > "E.g. if project P has test scoped dependency to a LIB1, and compile
> > > scoped dependency to LIB2, while LIB2 has compile scope dependency to
> > > LIB1, currently project P's war will wrongly end up without LIB1
> > > included. In P one expects LIB1 to be available for testing, but that
> > > shouldn't affect availability of LIB1 as compile scoped transitive
> > > dependency, it should be the other way round, in this case scope of
> > > declared test scoped dependency should be broadened."
> > >
> > > I used the term "override" to descibe the situation when project P
> > > should have LIB1 defined as a compile dependency, when the POM actually
> > > defines it as test. But it should should only override for test
> > > dependencies, not for provided or runtime.
> > >
> >
> > The local pom always wins. Placing additional semantics on how things
> merge
> > is troublesome. I'm sure we can think of scenarios where widening is not
> > the
> > right thing to do. In either case you must have the ability to resolve
> this
> > yourself if it doesn't do the right thing...and the way to do that is to
> > put
> > what you want in the local pom.
> >
> >
> > >
> > > As for your "lost me" comment I am not sure what you would like
> > > explained. Scope basically has multiple meanings. Compile/test are
> both
> > > related to requiring a dependency for compilation; runtime/provided are
> > > both related to requiring a dependency only at runtime. These multiple
> > > meanings are not suited to a single variable.
> > >
> >
> > Are there many cases where you want something for compilation that isn't
> > needed at runtime? I don't see them as being separate.
> >
> >
> > >
> > > ---
> > > Todd Thiessen
> > >
> > >
> >
>
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stevo Slavić <ss...@gmail.com>.
Is there any reason why would local win in this particular case?
Regards,
Stevo.
On Sun, May 10, 2009 at 5:26 AM, Brian Fox <br...@infinity.nu> wrote:
> On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen <th...@nortel.com>
> wrote:
>
> > Override the dependency defined in the POM, as Steve outline in his
> > earlier response. Let me quote his explanation for ease of reference:
> >
> > "E.g. if project P has test scoped dependency to a LIB1, and compile
> > scoped dependency to LIB2, while LIB2 has compile scope dependency to
> > LIB1, currently project P's war will wrongly end up without LIB1
> > included. In P one expects LIB1 to be available for testing, but that
> > shouldn't affect availability of LIB1 as compile scoped transitive
> > dependency, it should be the other way round, in this case scope of
> > declared test scoped dependency should be broadened."
> >
> > I used the term "override" to descibe the situation when project P
> > should have LIB1 defined as a compile dependency, when the POM actually
> > defines it as test. But it should should only override for test
> > dependencies, not for provided or runtime.
> >
>
> The local pom always wins. Placing additional semantics on how things merge
> is troublesome. I'm sure we can think of scenarios where widening is not
> the
> right thing to do. In either case you must have the ability to resolve this
> yourself if it doesn't do the right thing...and the way to do that is to
> put
> what you want in the local pom.
>
>
> >
> > As for your "lost me" comment I am not sure what you would like
> > explained. Scope basically has multiple meanings. Compile/test are both
> > related to requiring a dependency for compilation; runtime/provided are
> > both related to requiring a dependency only at runtime. These multiple
> > meanings are not suited to a single variable.
> >
>
> Are there many cases where you want something for compilation that isn't
> needed at runtime? I don't see them as being separate.
>
>
> >
> > ---
> > Todd Thiessen
> >
> >
>
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stephen Connolly <st...@gmail.com>.
2009/5/11 Todd Thiessen <th...@nortel.com>
> > I think the answer here is that nobody had a good example at the
> time!
>
> And even when you do, you can use exclusions which you interesting
> mention in your next response ;-). So if you want a particular compile
> transitive dependency to be included only as test, exclude it and add it
> to your local pom as test.
>
> I agree that the local pom should have precise control over how the
> "scope" of a dependency gets defined. But Maven is all about convention
> over configuration. If the convention is that compile scope should
> override test scope, then that is what maven should do by default. In
I thought that Maven issued a warning if a compile scope was downgraded to
test
but it would appear that I might be wrong in that case.
>
> the rare cases when a user wishes to change this behaviour, maven should
> provide a way to configure a transitive dependency manually. This is
> very similar in concept to marking a transitve dependency as exclude.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Todd Thiessen <th...@nortel.com>.
> I think the answer here is that nobody had a good example at the
time!
And even when you do, you can use exclusions which you interesting
mention in your next response ;-). So if you want a particular compile
transitive dependency to be included only as test, exclude it and add it
to your local pom as test.
I agree that the local pom should have precise control over how the
"scope" of a dependency gets defined. But Maven is all about convention
over configuration. If the convention is that compile scope should
override test scope, then that is what maven should do by default. In
the rare cases when a user wishes to change this behaviour, maven should
provide a way to configure a transitive dependency manually. This is
very similar in concept to marking a transitve dependency as exclude.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stephen Connolly <st...@gmail.com>.
2009/5/11 Todd Thiessen <th...@nortel.com>
>
> > Are there many cases where you want something for compilation
> > that isn't needed at runtime? I don't see them as being separate.
>
> Really? I am surprised. Yes there is a relation between compile and
> runtime. However, there is a different relation between compile and
> test. Scope has multiple meanings here. You have scope which defines
> when a dependency is needed (ie: at compile or runtime); or scope that
> defines what code a dependency is needed for (ie: test or main). Really,
> test scope means compile time (the when dimension of scope) for test
> code (the what code dimension of scope).
>
> For instance, how does one define a test dependency that is only needed
> at runtime? Two different concepts stored in one variable makes this
> cumbersome.
I think the answer here is that nobody had a good example at the time!
The primary issue that people want to control scope for is to ensure that:
1. They do not accidentally add compile time dependencies to implementations
of an API (this may be stated in different ways)
so for example, if I depend on the servlet-api I do not want to reference
tomcat classes from my code because I have broken portability of my code
hence the three scopes:
compile - put on compile and runtime classpaths.
provided - put on compile classpath only
runtime - put on runtime classpath only
The secondary issue is unit tests, we often need additional dependencies for
writing unit tests that we don't want to creep into our (non-test) code.
Also it can be useful to use GPL code when writing unit tests, although you
might not use the GPL code in your (non-test) code.
Thus enter
test - put on test classpath
I agree that perhaps we should separate the two sets of classpaths, i.e. the
(non-test) compile and runtime classpaths and the test compile and runtime
classpaths. But the pollution of runtime dependencies into test code is
less of an issue for unit tests.... Integration tests should go in their own
module and that gives you control over the compile and runtime classpaths of
that code
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Todd Thiessen <th...@nortel.com>.
> At test runtime I presume? You use the test scope. Is it
> hurting anything if it's there on the test compile classpath?
Its an example of how the scope definition is overloaded. Whether or not
it hurts anything is moot.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Tim Kettler <ti...@udo.edu>.
Brian Fox schrieb:
> On Mon, May 11, 2009 at 9:48 AM, Todd Thiessen <th...@nortel.com> wrote:
>
>>> Are there many cases where you want something for compilation
>>> that isn't needed at runtime? I don't see them as being separate.
>> Really? I am surprised. Yes there is a relation between compile and
>> runtime. However, there is a different relation between compile and
>> test. Scope has multiple meanings here. You have scope which defines
>> when a dependency is needed (ie: at compile or runtime); or scope that
>> defines what code a dependency is needed for (ie: test or main). Really,
>> test scope means compile time (the when dimension of scope) for test
>> code (the what code dimension of scope).
>>
>> For instance, how does one define a test dependency that is only needed
>> at runtime? Two different concepts stored in one variable makes this
>> cumbersome.
>>
>
> At test runtime I presume? You use the test scope. Is it hurting anything if
> it's there on the test compile classpath?
>
Isn't that true for the main classpath as well? So why do we have the
runtime scope at all?
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Brian Fox <br...@infinity.nu>.
On Mon, May 11, 2009 at 9:48 AM, Todd Thiessen <th...@nortel.com> wrote:
>
> > Are there many cases where you want something for compilation
> > that isn't needed at runtime? I don't see them as being separate.
>
> Really? I am surprised. Yes there is a relation between compile and
> runtime. However, there is a different relation between compile and
> test. Scope has multiple meanings here. You have scope which defines
> when a dependency is needed (ie: at compile or runtime); or scope that
> defines what code a dependency is needed for (ie: test or main). Really,
> test scope means compile time (the when dimension of scope) for test
> code (the what code dimension of scope).
>
> For instance, how does one define a test dependency that is only needed
> at runtime? Two different concepts stored in one variable makes this
> cumbersome.
>
At test runtime I presume? You use the test scope. Is it hurting anything if
it's there on the test compile classpath?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Todd Thiessen <th...@nortel.com>.
> Are there many cases where you want something for compilation
> that isn't needed at runtime? I don't see them as being separate.
Really? I am surprised. Yes there is a relation between compile and
runtime. However, there is a different relation between compile and
test. Scope has multiple meanings here. You have scope which defines
when a dependency is needed (ie: at compile or runtime); or scope that
defines what code a dependency is needed for (ie: test or main). Really,
test scope means compile time (the when dimension of scope) for test
code (the what code dimension of scope).
For instance, how does one define a test dependency that is only needed
at runtime? Two different concepts stored in one variable makes this
cumbersome.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Brian Fox <br...@infinity.nu>.
On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen <th...@nortel.com> wrote:
> Override the dependency defined in the POM, as Steve outline in his
> earlier response. Let me quote his explanation for ease of reference:
>
> "E.g. if project P has test scoped dependency to a LIB1, and compile
> scoped dependency to LIB2, while LIB2 has compile scope dependency to
> LIB1, currently project P's war will wrongly end up without LIB1
> included. In P one expects LIB1 to be available for testing, but that
> shouldn't affect availability of LIB1 as compile scoped transitive
> dependency, it should be the other way round, in this case scope of
> declared test scoped dependency should be broadened."
>
> I used the term "override" to descibe the situation when project P
> should have LIB1 defined as a compile dependency, when the POM actually
> defines it as test. But it should should only override for test
> dependencies, not for provided or runtime.
>
The local pom always wins. Placing additional semantics on how things merge
is troublesome. I'm sure we can think of scenarios where widening is not the
right thing to do. In either case you must have the ability to resolve this
yourself if it doesn't do the right thing...and the way to do that is to put
what you want in the local pom.
>
> As for your "lost me" comment I am not sure what you would like
> explained. Scope basically has multiple meanings. Compile/test are both
> related to requiring a dependency for compilation; runtime/provided are
> both related to requiring a dependency only at runtime. These multiple
> meanings are not suited to a single variable.
>
Are there many cases where you want something for compilation that isn't
needed at runtime? I don't see them as being separate.
>
> ---
> Todd Thiessen
>
>
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Todd Thiessen <th...@nortel.com>.
Override the dependency defined in the POM, as Steve outline in his
earlier response. Let me quote his explanation for ease of reference:
"E.g. if project P has test scoped dependency to a LIB1, and compile
scoped dependency to LIB2, while LIB2 has compile scope dependency to
LIB1, currently project P's war will wrongly end up without LIB1
included. In P one expects LIB1 to be available for testing, but that
shouldn't affect availability of LIB1 as compile scoped transitive
dependency, it should be the other way round, in this case scope of
declared test scoped dependency should be broadened."
I used the term "override" to descibe the situation when project P
should have LIB1 defined as a compile dependency, when the POM actually
defines it as test. But it should should only override for test
dependencies, not for provided or runtime.
As for your "lost me" comment I am not sure what you would like
explained. Scope basically has multiple meanings. Compile/test are both
related to requiring a dependency for compilation; runtime/provided are
both related to requiring a dependency only at runtime. These multiple
meanings are not suited to a single variable.
---
Todd Thiessen
> -----Original Message-----
> From: Brian Fox [mailto:brianf@infinity.nu]
> Sent: Friday, May 08, 2009 11:00 AM
> To: Maven Users List
> Subject: Re: Re: Transitive and inherited dependencies -
> potential bug, or my misunderstanding of the mechanism
>
> 2009/5/8 Todd Thiessen <th...@nortel.com>
>
> > Your argument Jorg I think applies to provided and runtime
> scope, but
> > not to test.
> >
> > The root smell here lies in the definition of "scope". Test scope
> > means needed to compile test code. Compile scope means needed to
> > compile production and test code. These are both related to when a
> > dependency is needed to compile.
> >
> > Provided and runtime scope are related to when a dependency
> is needed
> > at runtime.
> >
> > So the way I see it, a compile transitive dependency should always
> > override a test dependency but not provided or runtime.
> >
>
> What do you mean by override?
>
>
> >
> > There is some technical debt here in terms of how scoping
> works. You
> > really need a further scope classification like:
> >
> > Scope = compile
> > classifier = test
> > classifier = production
> >
> > Scope = runtime
> > classifier = provided
> >
> > Something like this. You likely get the idea.
> >
>
> Lost me....
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Brian Fox <br...@infinity.nu>.
2009/5/8 Todd Thiessen <th...@nortel.com>
> Your argument Jorg I think applies to provided and runtime scope, but not
> to test.
>
> The root smell here lies in the definition of "scope". Test scope means
> needed to compile test code. Compile scope means needed to compile
> production and test code. These are both related to when a dependency is
> needed to compile.
>
> Provided and runtime scope are related to when a dependency is needed at
> runtime.
>
> So the way I see it, a compile transitive dependency should always override
> a test dependency but not provided or runtime.
>
What do you mean by override?
>
> There is some technical debt here in terms of how scoping works. You really
> need a further scope classification like:
>
> Scope = compile
> classifier = test
> classifier = production
>
> Scope = runtime
> classifier = provided
>
> Something like this. You likely get the idea.
>
Lost me....
RE: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Todd Thiessen <th...@nortel.com>.
Your argument Jorg I think applies to provided and runtime scope, but not to test.
The root smell here lies in the definition of "scope". Test scope means needed to compile test code. Compile scope means needed to compile production and test code. These are both related to when a dependency is needed to compile.
Provided and runtime scope are related to when a dependency is needed at runtime.
So the way I see it, a compile transitive dependency should always override a test dependency but not provided or runtime.
There is some technical debt here in terms of how scoping works. You really need a further scope classification like:
Scope = compile
classifier = test
classifier = production
Scope = runtime
classifier = provided
Something like this. You likely get the idea.
---
Todd Thiessen
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Jörg Schaible
> Sent: Friday, May 08, 2009 9:11 AM
> To: users@maven.apache.org
> Subject: Re: Transitive and inherited dependencies -
> potential bug, or my misunderstanding of the mechanism
>
> Hi Stevo,
>
> Stevo Slavić wrote at Freitag, 8. Mai 2009 14:15:
>
> > Issue is elsewhere. Initial example I gave included
> inheritance, but
> > unwanted behavior happens even without it.
> >
> > E.g. if project P has test scoped dependency to a LIB1, and compile
> > scoped dependency to LIB2, while LIB2 has compile scope
> dependency to
> > LIB1, currently project P's war will wrongly end up without
> LIB1 included.
>
> This is the whole point: This is not wrong, Maven did it
> right! Actually we use scope narrowing to trim down
> dependencies that are not needed/only needed for test or
> provided by the container.
>
> > In P
> > one expects LIB1 to be available for testing, but that shouldn't
> > affect availability of LIB1 as compile scoped transitive
> dependency,
> > it should be the other way round, in this case scope of
> declared test
> > scoped dependency should be broadened.
>
> Although Maven helps you with Dependency management, it is
> still your task as dev to actively maintain them. This
> implies a check of the dependency tree.
>
> > As I wrote earlier, things are made worse by fact that
> during regular
> > packaging/install of such an artifact no warning message is printed
> > about narrower scope being chosen, so without appropriate
> (functional)
> > tests or checking of dependency:tree one ends up knowing that
> > dependency is missing only at runtime (it's a thril when it
> happens very late, at production...
> > :) ).
>
> Broadening the scope will have some really nasty other
> side-effects which will again put you in the role of actively
> maintaining the dep tree ;-)
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Stevo,
Stevo Slavić wrote at Freitag, 8. Mai 2009 14:15:
> Issue is elsewhere. Initial example I gave included inheritance, but
> unwanted behavior happens even without it.
>
> E.g. if project P has test scoped dependency to a LIB1, and compile scoped
> dependency to LIB2, while LIB2 has compile scope dependency to LIB1,
> currently project P's war will wrongly end up without LIB1 included.
This is the whole point: This is not wrong, Maven did it right! Actually we
use scope narrowing to trim down dependencies that are not needed/only
needed for test or provided by the container.
> In P
> one expects LIB1 to be available for testing, but that shouldn't affect
> availability of LIB1 as compile scoped transitive dependency, it should be
> the other way round, in this case scope of declared test scoped dependency
> should be broadened.
Although Maven helps you with Dependency management, it is still your task
as dev to actively maintain them. This implies a check of the dependency
tree.
> As I wrote earlier, things are made worse by fact that during regular
> packaging/install of such an artifact no warning message is printed about
> narrower scope being chosen, so without appropriate (functional) tests or
> checking of dependency:tree one ends up knowing that dependency is missing
> only at runtime (it's a thril when it happens very late, at production...
> :) ).
Broadening the scope will have some really nasty other side-effects which
will again put you in the role of actively maintaining the dep tree ;-)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Stevo Slavić <ss...@gmail.com>.
Issue is elsewhere. Initial example I gave included inheritance, but
unwanted behavior happens even without it.
E.g. if project P has test scoped dependency to a LIB1, and compile scoped
dependency to LIB2, while LIB2 has compile scope dependency to LIB1,
currently project P's war will wrongly end up without LIB1 included. In P
one expects LIB1 to be available for testing, but that shouldn't affect
availability of LIB1 as compile scoped transitive dependency, it should be
the other way round, in this case scope of declared test scoped dependency
should be broadened.
As I wrote earlier, things are made worse by fact that during regular
packaging/install of such an artifact no warning message is printed about
narrower scope being chosen, so without appropriate (functional) tests or
checking of dependency:tree one ends up knowing that dependency is missing
only at runtime (it's a thril when it happens very late, at production... :)
).
Regards,
Stevo.
On Fri, May 8, 2009 at 1:43 PM, Jörg Schaible <jo...@gmx.de> wrote:
> Mark Hobson wrote at Freitag, 8. Mai 2009 11:05:
>
> > 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?
>
> This would be the show stopper for me for ever using Mercury. If I narrow
> the scope in the local POM it is done *because I want it so*, e.g.
> preventing compile time deps to a specific implementation that's hidden
> behind an interface.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism
Posted by Jörg Schaible <jo...@gmx.de>.
Mark Hobson wrote at Freitag, 8. Mai 2009 11:05:
> 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?
This would be the show stopper for me for ever using Mercury. If I narrow
the scope in the local POM it is done *because I want it so*, e.g.
preventing compile time deps to a specific implementation that's hidden
behind an interface.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Mark Hobson <ma...@gmail.com>.
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 <br...@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ć <ss...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Transitive and inherited dependencies - potential bug, or my
misunderstanding of the mechanism
Posted by Brian Fox <br...@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ć <ss...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>