Fundamental issue here is having multiple ways to construct dependency
dirty DAG and prune the DAG to eliminate conflicts. Resolution starts
with artifact A using one strategy and then hits dependency artifact B
that uses another strategy. Forcing the same strategy on A and B will
almost certainly produce unexpected/undesired results.
--
Regards,
Igor
On 11-07-31 12:11 PM, Mark Struberg wrote:
Hi Igor!
I'm also not sure if it makes sense/works out to apply a different
DependencyResolver on per project base. This is also kind of a chicken-egg
problem.
But I could imaging that this could be done in settings.xml!
LieGrue,
strub
--- On Sun, 7/31/11, Igor Fedorenko<i...@ifedorenko.com> wrote:
From: Igor Fedorenko<i...@ifedorenko.com>
Subject: Re: Pluggable Dependency Resolution
To: dev@maven.apache.org
Date: Sunday, July 31, 2011, 7:51 AM
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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
