Brian E. Fox wrote:
I think you're questioning if you have this:
<dependencyManagement>
<dependencies>
<dependency>
<artifactId>foo</artifactId>
<groupId>com</groupId>
<version>1</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<artifactId>foo</artifactId>
<groupId>com</groupId>
<version>2</version>
</dependency>
</dependencies>
Should you get 1 or 2? Without the direct dependency, you should get 1 if pulled in transitively.
With the direct dependency as shown, you should get 2. I think you always need to maintain the
ability to override at a child level if needed.
No i'm not questioning that. With maven 2.0.5 and before you'd get 1, with
2.0.6 and later you get 2.
I'm questioning the dubious meaning of depMgt. you cannot tell wheter it was
created to declare overrides
for transitive deps, or wheter it was meant as defaults for direct deps. Either
way, as soon
as a direct dep is added resp. removed in any child module at any depth, the
meaning changes and you get a
different version. It's inconsistent, and you cannot tell what a
dependencyManagement section does (which version
of the dep you're goanna get) without looking at the entire module tree.
This has some consequences if the depMgt was inherited and sibling dependencies
are used since they
would ignore the declared direct dependency in some cases.
Is that why you think the behavior is wrong?
Exactly; they'd honor the direct dep, but if it's absent and there's a
transitive one, that one may win,
depending on how far the dep is away from a module.
P depMgt for E at 1.0
|
+ A dep on B, dep on C
+ B dep on C, dep on E 3.0
+ C dep on E version 2.0
+ D dep on E, no version
+ X dep on A, B, C, D
D would get E 1.0
C would get E 2.0
B would get E 3.0
A would get either 3.0 or 2.0
( A -> B -> E 3.0
A -> C -> E 2.0 )
X would get:
X -> A -> B -> E 3.0
X -> A -> C -> E 2.0
X -> B -> E 3.0
X -> B -> C -> E 2.0
X -> C -> E 2.0
X -> D -> E 1.0
Shortest paths are through B, C and D, so can get either 1.0, 2.0 or 3.0. Which is it?
According to my tests on 3 simple projects, since E is not a direct dep from X, the depMgt overrides
kick in and I should get E 1.0 on X, right?
It's way to confusing this way and totally not straightforward. An element can
change semantics
by something far away; that's not descriptive or deterministic or repeatable.
If we need 2 different ways to handle versions:
1) declare defaults for direct dependencies
2) declare overrides for transitive ones
we need a new element, like 'transitiveDependencyManagement'.
This is something I hope we won't support in 2.1...
-- Kenney
-----Original Message-----
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 16, 2007 7:06 AM
To: Maven Developers List
Subject: depMgt (mng-1577 again....)
Hi,
Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what
I found:
P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep
(I modified the attached project locally; rename my-app to my-dep and add
my-app with a dep on my-dep).
When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is used
for DEFAULTS for direct dependencies.
When building my-app, after installing P and my-dep, I get lucene 1.3. So
depMgt is used as OVERRIDE
for transitive dependencies.
When I add a dep on lucene without a version in my-app, I get 1.3 aswell.
When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2.
(luckily this also happens when building from the reactor).
This is one of the many possible implementations I described in
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification,
and it's one that I don't think we should support.
The meaning of depMgt is different, applied to either local deps or transitive
deps,
and it's not consistent.
This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct dependencies of
artifact X,
and for overrides of transitive dependencies on X,
unless there's also a direct dependency on X in which case the direct
dependency is used.
I'm sure this is not intended, so what should the intended behaviour be?
Either we keep the 'child overrides' that's globally present in all of maven,
so that dependencies
can override depMgt, as is the case now, and also apply that to transitive deps,
OR we let depMgt override both local and transitive deps.
Or, is this the intended behaviour after all?
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
