maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <i...@ifedorenko.com>
Subject Re: Pluggable Dependency Resolution
Date Sun, 31 Jul 2011 07:51:28 GMT
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message