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
