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.
