maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@sonatype.com>
Subject Re: Pluggable Dependency Resolution
Date Sat, 30 Jul 2011 23:58:42 GMT
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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.




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message