Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: unknown ipv4:66.48.80.0/25 (athena.apache.org: encountered
 unrecognized mechanism during SPF processing of domain of jason@sonatype.com)
From: Jason van Zyl <jason@sonatype.com>
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-27-903157264
Subject: Re: Pluggable Dependency Resolution
Date: Sat, 30 Jul 2011 19:58:42 -0400
In-Reply-To: <176D071A-BA8D-42F5-9881-FF394E1C485B@talios.com>
To: "Maven Developers List" <dev@maven.apache.org>
References: <176D071A-BA8D-42F5-9881-FF394E1C485B@talios.com>
Message-Id: <61EA0620-AC9E-4A22-852E-1A1DF2F9A41F@sonatype.com>

--Apple-Mail-27-903157264
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Jul 30, 2011, at 7:14 PM, Mark Derricutt wrote:

> Hi all,
>=20
> 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.
>=20
> 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.
>=20

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/MavenRepositorySystemSe=
ssion.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.

>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Thoughts?
>=20
> Mark
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>=20

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

To do two things at once is to do neither.
=20
 -=97Publilius Syrus, Roman slave, first century B.C.


--Apple-Mail-27-903157264--