IMHO, it can make sense as a CLI option, to let you try multiple strategies (normal, GUMP-like ie. LATEST, compatibility ie. OLDEST) But I doubt it has a meaning neither at project level nor user level, nor install level. Project level is IMHO impossible, like Igor seems to have tried :) User level or install level is feasible, but I don't find any useful use case, or giving headaches since we must check the strategy "installed" before trying to analyze anything
Regards, Hervé Le dimanche 31 juillet 2011, Mark Struberg a écrit : > Hi Igor! > > I'm also not sure if it makes sense/works out to apply a different > DependencyResolver on per project base. This is also kind of a chicken-egg > problem. But I could imaging that this could be done in settings.xml! > > LieGrue, > strub > > --- On Sun, 7/31/11, Igor Fedorenko <i...@ifedorenko.com> wrote: > > From: Igor Fedorenko <i...@ifedorenko.com> > > Subject: Re: Pluggable Dependency Resolution > > To: dev@maven.apache.org > > Date: Sunday, July 31, 2011, 7:51 AM > > It is sort-of possible to plug > > per-project dependency resolver and this > > is more or less how Tycho works already (I can provide more > > details > > about implementation, if you are interested). The problem > > is on the > > consumer end. What dependency resolution logic you expect > > to apply if > > standard maven project depends on an artifact built using > > custom > > resolver? What if both projects use custom resolvers? So > > far, we did not > > find an answer for just two resolution strategies (i.e. > > maven and > > tycho/p2/osgi) and I am afraid a general solution for N > > resolvers > > simply does not exist. > > > > -- > > Regards, > > Igor > > > > On 11-07-31 3:14 AM, Mark Derricutt wrote: > > > Hi all, > > > > > > I wanted to start this discussion completely separate > > > > from any of the > > > > > other, rather heated ASL vs EPL discussions around > > > > Aether to try and > > > > > keep this more on topic. > > > > > > For awhile we ( members of the Illegal Argument > > > > podcast ) have often > > > > > discussed a desire to have a pluggable dependency > > > > resolution > > > > > mechanism within Apache Maven, mostly around having > > > > the ability to > > > > > force maven to use the lowest bound in a range rather > > > > than the > > > > > highest for highlight fast-fail API breakages. > > > > > > With the rise of these ASF/EPL threads I again thought > > > > of the > > > > > pluggable resolution idea. For those with more > > > > of a code-centric > > > > > knowledge of the workings of Apache Maven, is it > > > possible/feasible/semi-cleanly-codeable to have an > > > > install, or even > > > > > project level selection of resolution of artifacts. > > > > > > I imagine a difficulty in that this would have to > > > > occur early in the > > > > > bootstrap process of maven, but if this were the case, > > > > would we not > > > > > be able to work a solution to not only the Aether > > > > inclusion issues, > > > > > but also Kasun's Gentoo resolution issues. > > > > > > This allows the end-user of Apache Maven (in the case > > > > that they care > > > > > about it) the ability to update artifact resolution > > > > code independent > > > > > of maven itself, or use a hardened/locked down > > > > resolution scheme > > > > > backed by portage - and portage only. > > > > > > Apache Maven could stick with (for now) using Aether > > > > 1.11, the last > > > > > dual licensed release out of the box, where as the > > > > Gentoo ebuild > > > > > could configure maven to use its own ( an idea I see > > > > as flawed > > > > > personally ) and those who wish to use Aether, or a > > > > custom resolution > > > > > strategy could do so. > > > > > > Thoughts? > > > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
