Jörg Schaible wrote:
Kenney Westerhof wrote:
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.
Yes.
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?
No, this was *exacltly* the intended behaviour! Do you know, how often we
have to add direct deps simply because depMgmt did not override the
transitive deps?
Ok, so you wanna be able to override transitive deps, that's fine; a good
usecase.
[snip]
Everytime a third-party dep is upgraded, you have to check all its
dependencies again. You never know in your EJB if the local deps are there
to override transitive one or if they are really necessary.
You have to do that too now, for your modules. If one module defines a
dependency
with a version different from your depMgt, you won't get the version specified
in depMgt.
You're shifting the problem with this solution..
Even worse, the transitive deps can change simply by adding a complete
unrelated dep in your component. All because the sequence the deps are
processed seems to be an iterator over a hash map. We had cases, were
adding a *unrelated* dep caused the compilation of an project to fail,
since suddenly a transitive dep was resolved in a different version.
Yeah, that's fixed since 2.0.5; when 2 deps at the same depth have different
versions,
a 'random' one is chosen, depending on the hash or set implementation of your
JRE.
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?
Yes, it is. Definitely for me and I reported 1577. Thanks again for those
guys who implemented it.
I'm ok with the fact that depMgt overrides versions. I just expected it to do
just that,
and not be a 'default' or 'override' depending on how many resolution nodes
away a dependency
was.
Say project A extends P where P declares depmgt for B 1.0,
and A needs B 2.0. Since dependency versions are 'hints' anyway, they shouldn't
be used to override
something that's designed to override; just use the override mechanism already
there - the depMgt.
Inheritance will make sure that any depMgt section in A overrides depMgt
sections in P, so you
still can have what you want.
If I see a depMgt section now, I have no clue what the intent was - defaults or
overrides?
I'd have to scan the entire module tree to find out; and even then, it could be
that for a subset
of modules it was meant as an override, and for another subset as defaults.
The project as a whole will have problems since there are 2 versions for a
given artifact, and
depending on the depth, one of them will be chosen. This is very bad imho.
-- Kenney
- Jörg
---------------------------------------------------------------------
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]
