On 13/12/2011, at 7:50 AM, Steve Ebersole wrote:
> Hmm, my understanding is that <dependencyManagement/> affects transitive
> dependencies whereas <dependencies/> does not.
>
dependencyManagement does affect the resolution of transitive dependencies, in
a fashion similar to forced. That is, if I have a dependency chain A -> B -> C,
I can affect the version of A brought in by C using the <dependencyManagement>
section. It's a _little_ misleading to say that dependencies don't do this,
because I can declare a dependency on A directly in C if I like - it's just
that it's not transitive then.
The version of A specified in C - either via a direct dependency or
dependencyManagement - will take precedence over the version of A specified in
B.
Forced versions in Gradle provide a similar function in that they determine the
result of transitive dependency resolution. Where they differ is that these
dependencies are themselves transitive in Maven, but not in Gradle. That is to
say, if I introduce another module - D - that depends on C, then the
dependencyManagement in C is used by Maven, but the forced versions in Gradle
are not (at least not at the time of writing).
Version ranges, however, are different again. Version ranges don't (directly)
specify the resulting version - they affect the _allowable_ versions. While the
'soft requirement' version has numerous precedence rules, with only the highest
precedence being used, this soft requirement must match the intersection of all
version ranges declared in the transitive dependency chain.
--
"Software is too expensive to build cheaply"
Robert Watkins twitter: @twasink http://twasink.net/ [email protected]
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
