I should actually add that depMgmt actually happens at TWO levels in a
graph:
1. the top-level that enforces versions/scope/exclusions for the whole graph
2. the direct project (or parent) that declares the dependency to be managed
This makes sense, if you think about it: if you leave a version out of
the dependency you declare, you expect to fill it in from your POM's or
a parent POM's dependencyManagement...if Maven didn't do this, that dep
declaration would be invalid.
The problem is that depMgmt in the layers of the graph between my
project and that project declaring the dependency are discarded.
On 5/20/13 9:15 AM, John Casey wrote:
This is something I've seen in the wild in the past couple of weeks,
too. I had to mock it up and see it for myself before I believed the user.
Personally, option A makes the most sense to me. The reason is in
Geoffrey's third slide...I would expect MyProject to simply append the
dependency graph used by YourProject if I declare it as a dependency. I
don't care *how* Maven arrives at that dependency graph, I just want it
to be consistent between times when that project is used by itself and
when I'm depending on it.
That is, I want it consistent UNLESS I override something at my level.
And if I do override something at my level, that override statement
metadata that others should be able to take advantage of, just like any
dependency declaration I make.
I actually think this is the only consistent way to approach the problem.
On 5/19/13 1:28 PM, Jason van Zyl wrote:
Checking them out. It's not that I didn't agree with you the first
time :-) It really is a matter of how to introduce and not introduce
any discrepancies in behaviour. The general solution is to look at the
dependencies of your final runtime and constrain them in the depMgmt
section that you control. The way the nearest rule and depMgmt
behaviour currently work bing altered would cause problems unless we
tied a particular convention to a particular version of a POM. Having
one version of Maven resolve a project one way and another version of
Maven resolve it differently would probably be very confusing.
A) Would cause a resolution behaviour issue.
B) Don't you think what currently exists is simpler where you
understand the composition of your application and control it from the
depMgmt section in your project?
C) I have no doubt improvements can be made in general, and in a
standard, but completely pluggable resolution i think is unworkable
generally.
I'll load up your POMs and take a look.
On May 19, 2013, at 1:57 PM, Geoffrey De Smet
<[email protected]> wrote:
On 19-05-13 17:18, Jason van Zyl wrote:
I can show you visually whats happening and it's not so much a bug
(which I think I explained to you when you showed me the slides
initially) but the current design.
I'd like to propose to review the current design.
Here are some idea's for an improved design:
A) Make dependencyManagement transitive: Apply the inherited
dependencyManagement on yourproject before processing it in myproject.
Or simply put: the dependency graph that yourproject compiles and
build with, is the same dependency subgraph that myproject
incorporates due to depending on yourproject.
B) Transitive dependencies overrides should be declared within the
element of the dependency, just like <excludes>.
For example:
<dependency>...
<artifactId>a</artifactId>
<transitiveDependencieOverrides>
<dependency>
<artifactId>jbpm-flow</artifactId>
<version>5.3.0.Final</version>
</dependency>
</transitiveDependencieOverrides>
</dependency>
If a is upgraded and a no longer depends on jbpm, this gives an error.
If a is upgraded and the new version of a requires a higher jbpm-flow,
then the guy upgrading a would notice that we explicitly overwrote
the jbpm-flow in the past,
so there's at least a chance he upgrades jbpm-flow too (and doesn't
run into NoSuchMethodError (*)).
Declaring a "normal" dependency just to override transitive
dependency (regardless if it's in dependencyManagement or not)
is in practice a maintenance nightmare, but it's the only option
that's available now. B) would fix that.
C) Pluggable conflict resolution
Out-of-the-box, we should have:
1) "the nearest" (which is part of the reason that the version of
direct dependencies win).
2) "the highest version (according to lexicographic version number
comparison)".
Any sane project will want to use 2): When "the nearest" rule decides
to use the lowest version of 2 versions, it's asking for a
NoSuchMethodError (*).
(*) If you're lucky, in your test coverage. If you're unlucky, in
production.
Compilation doesn't see it because dependencies are not recompiled.
HTH :)
On May 19, 2013, at 11:05 AM, Jason van Zyl <[email protected]> wrote:
You have the POMs handy you made the slides from?
On May 17, 2013, at 11:42 AM, Geoffrey De Smet
<[email protected]> wrote:
I've always believed this is a bug, not a feature. I am still
hoping to convince Jason etc of that.
I talked about this last year already at Devoxx 2012 in my session
"Maven dependency puzzlers".
I had several reactions that "this must be a bug".
Just look at 3 slides, and tell me maven 3.0.4 does the sane thing:
The setup (click right to go the next slide)
http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#34.0
How maven 3.0.4 resolved it:
http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#35.0
And what this means for users:
http://ge0ffrey.github.io/maven-dependency-puzzlers/maven-dependency-puzzlers-presentation/src/main/presentation/index.html#36.0
Look at that last slide and tell me this is not a bug.
wkr,
Geoffrey
On 09-04-13 13:38, Arnaud Héritier wrote:
Yes when I analyzed the behavior, seeing it was here for long
long time I
understood that it was probably done by design.
I had a look at our doc (
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management)
and we should probably detail more this behavior which is local
to the
currently built project (At least to be sure to be able to say
RTFM).
I'm not the only one to have supposed the wrong behavior which in
users
mind is more a bug than a feature
On Tue, Apr 9, 2013 at 12:59 PM, Jason van Zyl <[email protected]>
wrote:
This is how is was designed to work. Aether can do anything but the
original implementation is simply a map of GAs with a version
preference.
If the GA is encountered then its version is overridden. This
effectively
gives you a target platform like mechanism but is intended to be
controlled
from the final application. Maven does not consider depMan at
every level
in the tree. It's a global map controlled from your project and its
functionality is very limited in scope. You would need to do some
relatively sophisticated conflict resolution to have every sub
graph and
its managed dependencies be reconciled with every other. Not
that it can
not be done but this certainly not how dependency management is
implemented
currently. This is not a bug, this is how the feature is
implemented.
On 2013-04-08, at 8:28 AM, Arnaud Héritier <[email protected]>
wrote:
Hi all (and especially Herve, Jason and those who are working
on Aether),
We are several to hit what we consider to be a bug but myself I
don't
understand how we did to not see it before.
To be short the problem resides in depMgt usage. It is useful
only in the
project you are building to enforce/lock some versions. If this
is in a
transitive path of a dep it is unused.
For example here is a sample :
http://parleys.com/#play/515ef261e4b0cb5a00d98074/chapter34/about
The code to test :
https://github.com/ndeloof/maven-puzzler/tree/master/3
As far as we don't define the version in the depMgt of the
project itself
Maven will use the one from dependencies and won't take care of
any other
depMgt in the transitive path
Vincent Massol also reproduced it at code level here :
http://jira.codehaus.org/browse/MNG-5462
If someone could have a look at this issue please.
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
---------------------------------------------------------------------
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
The modern conservative is engaged in one of man's oldest exercises
in moral philosophy; that is,
the search for a superior moral justification for selfishness.
-- John Kenneth Galbraith
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
