You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Shane Isbell <sh...@gmail.com> on 2009/01/09 19:06:15 UTC
Maven 3.x: Dependency Management
I've run into an issue where the current behavior of building a project
model in Maven 2.0.x seems wrong. In the case of inheritance of dependency
scope, there is a default value of "compile". This default will override the
parent scope. This part is correct. But if the dependency scope is not
specified, the default value CAN be overridden by the dependency management
section of the pom. So in one case, the default value can't be overridden,
but in the other case it can.
I'm thinking that both dependencyManagement and inheritance should function
the same in Maven 3. If the developer doesn't specify a value, the default
value should be applied to the model (prior to any inheritance or
management). This would mean that dependencyManagement dependency container
will not be joined with a dependency container, unless the scope specified
in one matched the default scope in the other. Thoughts?
Shane
Re: Maven 3.x: Dependency Management
Posted by Shane Isbell <sh...@gmail.com>.
On Fri, Jan 9, 2009 at 10:35 AM, Oleg Gusakov
<ol...@gmail.com>wrote:
>
> Shane Isbell wrote:
>
>> I've run into an issue where the current behavior of building a project
>> model in Maven 2.0.x seems wrong. In the case of inheritance of dependency
>> scope, there is a default value of "compile". This default will override
>> the
>> parent scope. This part is correct. But if the dependency scope is not
>> specified, the default value CAN be overridden by the dependency
>> management
>> section of the pom. So in one case, the default value can't be overridden,
>> but in the other case it can.
>>
>>
>>
> In Mercury ommitted scope is always set to compile, regardless on
> inheritance. But POM is proceessed by Maven, and whatever mechanism is used
> there - Mercury gets back.
That raises an interesting point because if you specify scope as 'compile'
explicitly, as you do in Mercury, dependencyManagement will apply
differently than having scope 'compile' implicitly given. It's even more
important to get this defined correctly with Mercury in the mix.
Shane
Re: Maven 3.x: Dependency Management
Posted by Oleg Gusakov <ol...@gmail.com>.
Shane Isbell wrote:
> I've run into an issue where the current behavior of building a project
> model in Maven 2.0.x seems wrong. In the case of inheritance of dependency
> scope, there is a default value of "compile". This default will override the
> parent scope. This part is correct. But if the dependency scope is not
> specified, the default value CAN be overridden by the dependency management
> section of the pom. So in one case, the default value can't be overridden,
> but in the other case it can.
>
>
In Mercury ommitted scope is always set to compile, regardless on
inheritance. But POM is proceessed by Maven, and whatever mechanism is
used there - Mercury gets back.
I think that both inheritance and dep. management should treat scope
ommittion as compile to avoid contradictions.
Thanks,
Oleg
> I'm thinking that both dependencyManagement and inheritance should function
> the same in Maven 3. If the developer doesn't specify a value, the default
> value should be applied to the model (prior to any inheritance or
> management). This would mean that dependencyManagement dependency container
> will not be joined with a dependency container, unless the scope specified
> in one matched the default scope in the other. Thoughts?
>
> Shane
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3.x: Dependency Management
Posted by Ralph Goers <ra...@dslextreme.com>.
I think I may need a concrete example to make sure I understand the
issue properly. However, in my opinion dependency management
specifications should be used for anything not explicitly specified.
For example,
<project>
<arifactId>parent</artifactId>
<dependencyManagement>
<dependencies>
<dependency>
<artifactId>foo</artifactId>
<version>1.0.0</version>
<scope>runtime</scope>
<dependency>
<dependencies>
</dependencyManagement>
</project>
<project>
<parent>
<artifactId>parent</artifactId>
</parent>
<artifactId>child</artifactId>
<dependency>
<artifactId>foo</artifactId>
</dependency>
</project>
results in version 1.0.0 with scope runtime.
<project>
<parent>
<artifactId>parent</artifactId>
</parent>
<artifactId>child</artifactId>
<dependency>
<artifactId>foo</artifactId>
<scope>compile</scope>
</dependency>
</project>
results in version 1.0.0 with scope compile.
<project>
<artifactId>bar</artifactId>
<dependency>
<artifactId>foo</artifactId>
<scope>compile</scope>
</dependency>
</project>
<project>
<parent>
<artifactId>parent</artifactId>
</parent>
<artifactId>child</artifactId>
<dependency>
<artifactId>bar</artifactId>
<scope>compile</scope>
</dependency>
</project>
results in foo being version 1.0.0 with scope compile (since bar is a
transitive dependency).
Ralph
On Jan 9, 2009, at 10:06 AM, Shane Isbell wrote:
> I've run into an issue where the current behavior of building a
> project
> model in Maven 2.0.x seems wrong. In the case of inheritance of
> dependency
> scope, there is a default value of "compile". This default will
> override the
> parent scope. This part is correct. But if the dependency scope is not
> specified, the default value CAN be overridden by the dependency
> management
> section of the pom. So in one case, the default value can't be
> overridden,
> but in the other case it can.
>
> I'm thinking that both dependencyManagement and inheritance should
> function
> the same in Maven 3. If the developer doesn't specify a value, the
> default
> value should be applied to the model (prior to any inheritance or
> management). This would mean that dependencyManagement dependency
> container
> will not be joined with a dependency container, unless the scope
> specified
> in one matched the default scope in the other. Thoughts?
>
> Shane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org