On 19-05-13 17:05, Jason van Zyl wrote:
You have the POMs handy you made the slides from?
Yes :) Each puzzler in my presentation was tested out with this source code:
https://github.com/ge0ffrey/maven-dependency-puzzlers
That particular problem is in here:
https://github.com/ge0ffrey/maven-dependency-puzzlers/tree/master/child-with-dependencyManagement
Ignore the "fix" directory, which is a way to fix the bug by using boms
(which didn't work, but I've haven't tried decently yet).
The other dirs are modules as shown in the slides.
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.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
