You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Geoffrey De Smet <ge...@gmail.com> on 2013/05/17 17:42:26 UTC
Re: DepMgt is useless because not transitive
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 <ja...@tesla.io> 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 <ah...@gmail.com> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DepMgt is useless because not transitive
Posted by Jason van Zyl <ja...@tesla.io>.
So if I back you up a bit, what is the problem you're actually trying to solve?
Put aside right now what Maven is doing and describe what you want ideally and for what purpose? I can see the examples but I'm not sure what you're trying to make easier and for who.
In Maven you've got a bunch of things happening which may not yield ideal results: we have the nearest selector working, soft versions that wiggle around trying to find a viable solution, inheritance in depMgmt and the final map of depMgmt that constrains everything from the current project.
So maybe, I might suggest, you represent what you would ideally like to see as the input and what your desired output would be. You don't even need to represent it in a POM, but show what you want and then we'll figure out how it might possibly be wedged into Maven.
The problem with A) below is that it would certainly yield a different result if a dependency had a depMgmt section that was promoted into the current project while you had none in the current project's POM to begin with.
The current implementation might not allow automatic selection the way you would like but does allow the application owner to be the final arbiter of what is selected by locking it down within the current project's depMgmt section.
What I see is something akin to resolving and doing conflict resolution amongst many target platforms (Eclipse speak). If you rely on many things that say "i know what the final set of artifacts should be by stating it in my depMgmt section" and you want to combine all those then you are basically going to have to do a similar conflict resolution for everything that is participating and competing to determine who's version of what wins. This is not technically hard but it's not immediately obvious to me what strategy makes the most sense to resolve the conflicts.
On May 19, 2013, at 1:57 PM, Geoffrey De Smet <ge...@gmail.com> 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 <ja...@tesla.io> wrote:
>>
>>> You have the POMs handy you made the slides from?
>>>
>>> On May 17, 2013, at 11:42 AM, Geoffrey De Smet <ge...@gmail.com> 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 <ja...@tesla.io> 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 <ah...@gmail.com> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: DepMgt is useless because not transitive
Posted by Paul Gier <pg...@redhat.com>.
Another possible solution would be to change the dependency versions in
the pom before deployment to the repository. So when you build
"yourproject" the pom is updated, maybe in the target directory, to
reflect the dependency versions that were used during the build, and the
imported depMgmt pom could be removed, or just safely ignored. The
behavior could be similar to the shade plugin where the pom on disk is
left unmodified.
On 05/19/2013 12:57 PM, Geoffrey De Smet 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 <ja...@tesla.io> wrote:
>>
>>> You have the POMs handy you made the slides from?
>>>
>>> On May 17, 2013, at 11:42 AM, Geoffrey De Smet
>>> <ge...@gmail.com> 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 <ja...@tesla.io> 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 <ah...@gmail.com>
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DepMgt is useless because not transitive
Posted by John Casey <jd...@commonjava.org>.
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
>> <ge...@gmail.com> 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 <ja...@tesla.io> wrote:
>>>>
>>>>> You have the POMs handy you made the slides from?
>>>>>
>>>>> On May 17, 2013, at 11:42 AM, Geoffrey De Smet
>>>>> <ge...@gmail.com> 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 <ja...@tesla.io>
>>>>>>> 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 <ah...@gmail.com>
>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DepMgt is useless because not transitive
Posted by John Casey <jd...@commonjava.org>.
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 <ge...@gmail.com> 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 <ja...@tesla.io> wrote:
>>>
>>>> You have the POMs handy you made the slides from?
>>>>
>>>> On May 17, 2013, at 11:42 AM, Geoffrey De Smet <ge...@gmail.com> 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 <ja...@tesla.io> 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 <ah...@gmail.com> 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: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DepMgt is useless because not transitive
Posted by Jason van Zyl <ja...@tesla.io>.
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 <ge...@gmail.com> 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 <ja...@tesla.io> wrote:
>>
>>> You have the POMs handy you made the slides from?
>>>
>>> On May 17, 2013, at 11:42 AM, Geoffrey De Smet <ge...@gmail.com> 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 <ja...@tesla.io> 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 <ah...@gmail.com> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: DepMgt is useless because not transitive
Posted by Geoffrey De Smet <ge...@gmail.com>.
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 <ja...@tesla.io> wrote:
>
>> You have the POMs handy you made the slides from?
>>
>> On May 17, 2013, at 11:42 AM, Geoffrey De Smet <ge...@gmail.com> 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 <ja...@tesla.io> 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 <ah...@gmail.com> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DepMgt is useless because not transitive
Posted by Jason van Zyl <ja...@tesla.io>.
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.
On May 19, 2013, at 11:05 AM, Jason van Zyl <ja...@tesla.io> wrote:
> You have the POMs handy you made the slides from?
>
> On May 17, 2013, at 11:42 AM, Geoffrey De Smet <ge...@gmail.com> 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 <ja...@tesla.io> 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 <ah...@gmail.com> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> 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
Re: DepMgt is useless because not transitive
Posted by Geoffrey De Smet <ge...@gmail.com>.
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 <ge...@gmail.com> 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 <ja...@tesla.io> 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 <ah...@gmail.com> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DepMgt is useless because not transitive
Posted by Jason van Zyl <ja...@tesla.io>.
You have the POMs handy you made the slides from?
On May 17, 2013, at 11:42 AM, Geoffrey De Smet <ge...@gmail.com> 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 <ja...@tesla.io> 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 <ah...@gmail.com> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)