Jason, behaviour != implementation ! If someone likes to store his artifacts in a database or taking it from a p4, why not?
And actually having a much cleaner interface on our side would be highly welcome! LieGrue, strub --- On Sat, 7/30/11, Jason van Zyl <ja...@sonatype.com> wrote: > From: Jason van Zyl <ja...@sonatype.com> > Subject: Re: Pluggable Dependency Resolution > To: "Maven Developers List" <dev@maven.apache.org> > Date: Saturday, July 30, 2011, 11:58 PM > On Jul 30, 2011, at 7:14 PM, 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. > > > > I think the potential for wreaking havoc would be too high. > If it's something that is thought to be generally beneficial > we should add it. But how would you stop everyone and their > brother from thinking they had a better scheme? They all > deploys those schemes and then Maven has to deal with > potentially incompatible schemes and the default behaviour > becoming meaningless. This is why OSGi has a specification > on the scheme and the interpretation and you live with the > one way for the sake of it working consistently for > everyone. The idea seems appealing but I believe it would > make the system too fragile. > > > 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. > > Sure, it's possible. Maven's behavior is setup in the Maven > specific RepositorySystemSession: > > http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemSession.java > > This describes what the various bits do: > > http://aether.sonatype.org/introduction.html > > Right now nothing changes in the session once it starts up, > and there are no extension points in our particular session. > All I see is problems really. If this were project specific > we would have to be able to load the scheme from wherever it > came from and then determining whether the scheme or > interpretations were the same would be problematic. In your > particular case where you want to change something like the > behaviour of a bound ... maybe that's less problematic but I > think everyone living with one defined behavior and it being > augmented as a community would be wiser. In OSGi this > doesn't really change now because so many people depend on a > very specific behaviour. I don't think this would be a great > idea, and I'm not convinced it could even work. > > > > > 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 > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > To do two things at once is to do neither. > > -—Publilius Syrus, Roman slave, first century B.C. > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
