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 <[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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
