You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Derricutt <ma...@talios.com> on 2011/07/31 01:14:57 UTC
Pluggable Dependency Resolution
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
Re: Pluggable Dependency Resolution
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
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<ig...@ifedorenko.com> wrote:
>
>> From: Igor Fedorenko<ig...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Hervé BOUTEMY <he...@free.fr>.
IMHO, it can make sense as a CLI option, to let you try multiple strategies
(normal, GUMP-like ie. LATEST, compatibility ie. OLDEST)
But I doubt it has a meaning neither at project level nor user level, nor
install level.
Project level is IMHO impossible, like Igor seems to have tried :)
User level or install level is feasible, but I don't find any useful use case,
or giving headaches since we must check the strategy "installed" before trying
to analyze anything
Regards,
Hervé
Le dimanche 31 juillet 2011, Mark Struberg a écrit :
> 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 <ig...@ifedorenko.com> wrote:
> > From: Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Mark Struberg <st...@yahoo.de>.
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 <ig...@ifedorenko.com> wrote:
> From: Igor Fedorenko <ig...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
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
Re: Pluggable Dependency Resolution
Posted by Mark Derricutt <ma...@talios.com>.
On 31/07/2011, at 11:14 AM, Mark Derricutt wrote:
> 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.
Replying to my own post ;-)
I was just having the thought that doing something like moving the toolchains-plugin into core, and making use of this as a means to choose your dependency resolution.
If we combined this idea with the discussion of a new version of the POM, we could introduce a new <toolchains/> element inside of <build/> whilst preserving backwards compatibility of declaring the toolchain plugin maybe?
The superpom could declare a dependency <toolchain/> for the system default/standard resolution. And any users who want something custom would need to define it both in their pom, and there ~/.m2/toolchains.xml file - viable?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Stephen Connolly <st...@gmail.com>.
ok, in the past i have had discussions with Jason over version range syntax.
Jason previously expoused the view that osgi format version numbers is the
-only- way to have version numbers, and anything else he would not support.
at the time i was working for a company where we had 5 segment version
numbers.
major.minor.servicepack.patch.build
and the reality is that we needed all 5.
if version ranges can work with any number of segments, that solves my itch
(besides working for a new company without such issues)
qualifier sorting is something where i see being opinionated as a value, but
number of segments is not.
the other case is where you need to change the scheme. rpm has a second
field called, iirc epoch. it is integer and increments when you change the
version number scheme... if we had provides scope then we just say change G
or A coordinates... otherwise we need some epoch like support to version
numbering.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Jul 2011 11:19, "Hervé BOUTEMY" <he...@free.fr> wrote:
> Le dimanche 31 juillet 2011, Mark Derricutt a écrit :
>> The use case that we originally came with in our discussions revolved
>> around version ranges,
> ok, that's not a version comparison but version (range) resolution
question:
> version ordering is here to define how artifacts are ordered, then the
range
> has to choose which one is to be used effectively
> Multiple strategies can make sens here, but we should be careful on how to
> provide them.
>
> This lets the question of pluggable version comparison need: is there a
real
> world example of unwanted version order?
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: Pluggable Dependency Resolution
Posted by Mark Derricutt <ma...@talios.com>.
Not from any of my use cases no.
Mark
On 31/07/2011, at 10:18 PM, Hervé BOUTEMY wrote:
> This lets the question of pluggable version comparison need: is there a real
> world example of unwanted version order?
Re: Pluggable Dependency Resolution
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 31 juillet 2011, Mark Derricutt a écrit :
> The use case that we originally came with in our discussions revolved
> around version ranges,
ok, that's not a version comparison but version (range) resolution question:
version ordering is here to define how artifacts are ordered, then the range
has to choose which one is to be used effectively
Multiple strategies can make sens here, but we should be careful on how to
provide them.
This lets the question of pluggable version comparison need: is there a real
world example of unwanted version order?
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Mark Derricutt <ma...@talios.com>.
Potentially not. I suppose if there was a way to say [2.0.0,3.0.0) *excluding SNAPSHOTS* then that would certainly be in my favor.
From memory there was a discussion some time ago regarding range resolution excluding -SNAPSHOTs unless the artifacts were also in the current reactor build, from memory the discussion was last stalled around whether to have a command line arg for this, or to introduce something like <build><allowExternalSnapshots/></build>.
On 31/07/2011, at 11:58 PM, Jason van Zyl wrote:
> What if you could find another way to check API compatibility, would you need this at all?
Re: Pluggable Dependency Resolution
Posted by Stuart McCulloch <mc...@gmail.com>.
On 31 Jul 2011, at 13:15, Mark Struberg wrote:
> I thought about that too, and actually don't think that there is a general solution.
>
> Two examples:
>
> * JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new getParentLogger() method. To compile your own DataSource with java7 you need to implement this method. It is perfectly compatible to get executed on java5 and 6 too, so what you need is the latest version of the dependency (JDBC-4.1) while compiling your project. If you get invoked as a callback or similar, it's a good idea to implement the widest possible range.
>
> * The story turns around if you act as a client invoking other libs. If interfaces you use in your projects got extended with new methods in a new version, then this will obviously not work together with older lib versions once you made use of the new methods. In this case you should restrict yourself to the subset of methods available in all versions of the lib.
FYI, those are the two classic provider vs consumer scenarios:
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
> Plus, there are lots of grey tones between those 2 scenarios. E.g. if some method parameter or config tag expresses version and capability...
>
> LieGrue,
> strub
>
> PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin.
>
> --- On Sun, 7/31/11, Jason van Zyl <ja...@sonatype.com> wrote:
>
>> From: Jason van Zyl <ja...@sonatype.com>
>> Subject: Re: Pluggable Dependency Resolution
>> To: "Maven Developers List" <de...@maven.apache.org>
>> Date: Sunday, July 31, 2011, 11:58 AM
>> What if you could find another way to
>> check API compatibility, would you need this at all?
>>
>> On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote:
>>
>>> The use case that we originally came with in our
>> discussions revolved around version ranges, and the fact
>> that a version reference of "2.5.4" doesn't actually mean "
>> give me 2.5.4" but rather "I would like 2.5.4, but meh, use
>> something higher if you need to".
>>>
>>> In the case were you have artifacts using say
>> [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will
>> favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1,
>> and 2.5.0 are available, maven will choose 1.6.0 to compile
>> against.
>>>
>>> What we were discussing was that ideally you'd to
>> compile against the lowest lower bound ( 1.5.1 ), this way
>> you'd get fail fast on any changed APIs that you
>> inadvertently started to use, alerting you to the fact that
>> you need to increment the lower bound of your range.
>>>
>>> If you require bug fixes in a newer release which is
>> triggering your tests to fail, then you should also be
>> incrementing the lower bound.
>>>
>>> The whole purpose of this flow is to drive you to
>> releasing often, and working off binary dependencies rather
>> than long standing -SNAPSHOTs. This flow would seem to
>> work best for places who are releasing artifacts every 2-3
>> days, and working in a continuous delivery style process -
>> it probably wouldn't work for Apache projects which often
>> seem to favor long drawn out cycles ( I recall a thread
>> awhile ago about not wanting to release a plugin cause it
>> only had one bug fix in it ).
>>>
>>>
>>> Having read the other comments I realize my initial
>> idea is a little crazy, and as Jason pointed out in the
>> first response, probably more trouble than its worth.
>>>
>>> Mark
>>>
>>>
>>>
>>>
>>> On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote:
>>>
>>>> Do you have practical examples that either are not
>> supported, or the actual
>>>> ordering is the contrary than you expected?
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Ralph Goers <ra...@dslextreme.com>.
What you are suggesting here is something I've been advocating for the last several years - adding "provides" and "requires" to poms to indicate versions of things they require that are more granular than the jar. In the example below the driver might support several JDBC versions. Specifying just the groupId, artifactId and the subcomponent version(s) ought to allow Maven to choose the latest (or earliest if desired) version that fulfills those requirements. Likewise, if a managed dependency specifies the version of the artifact and error could be thrown if that artifact doesn't meet the requirements.
Ralph
On Jul 31, 2011, at 5:15 AM, Mark Struberg wrote:
> I thought about that too, and actually don't think that there is a general solution.
>
> Two examples:
>
> * JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new getParentLogger() method. To compile your own DataSource with java7 you need to implement this method. It is perfectly compatible to get executed on java5 and 6 too, so what you need is the latest version of the dependency (JDBC-4.1) while compiling your project. If you get invoked as a callback or similar, it's a good idea to implement the widest possible range.
>
> * The story turns around if you act as a client invoking other libs. If interfaces you use in your projects got extended with new methods in a new version, then this will obviously not work together with older lib versions once you made use of the new methods. In this case you should restrict yourself to the subset of methods available in all versions of the lib.
>
> Plus, there are lots of grey tones between those 2 scenarios. E.g. if some method parameter or config tag expresses version and capability...
>
> LieGrue,
> strub
>
> PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin.
>
> --- On Sun, 7/31/11, Jason van Zyl <ja...@sonatype.com> wrote:
>
>> From: Jason van Zyl <ja...@sonatype.com>
>> Subject: Re: Pluggable Dependency Resolution
>> To: "Maven Developers List" <de...@maven.apache.org>
>> Date: Sunday, July 31, 2011, 11:58 AM
>> What if you could find another way to
>> check API compatibility, would you need this at all?
>>
>> On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote:
>>
>>> The use case that we originally came with in our
>> discussions revolved around version ranges, and the fact
>> that a version reference of "2.5.4" doesn't actually mean "
>> give me 2.5.4" but rather "I would like 2.5.4, but meh, use
>> something higher if you need to".
>>>
>>> In the case were you have artifacts using say
>> [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will
>> favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1,
>> and 2.5.0 are available, maven will choose 1.6.0 to compile
>> against.
>>>
>>> What we were discussing was that ideally you'd to
>> compile against the lowest lower bound ( 1.5.1 ), this way
>> you'd get fail fast on any changed APIs that you
>> inadvertently started to use, alerting you to the fact that
>> you need to increment the lower bound of your range.
>>>
>>> If you require bug fixes in a newer release which is
>> triggering your tests to fail, then you should also be
>> incrementing the lower bound.
>>>
>>> The whole purpose of this flow is to drive you to
>> releasing often, and working off binary dependencies rather
>> than long standing -SNAPSHOTs. This flow would seem to
>> work best for places who are releasing artifacts every 2-3
>> days, and working in a continuous delivery style process -
>> it probably wouldn't work for Apache projects which often
>> seem to favor long drawn out cycles ( I recall a thread
>> awhile ago about not wanting to release a plugin cause it
>> only had one bug fix in it ).
>>>
>>>
>>> Having read the other comments I realize my initial
>> idea is a little crazy, and as Jason pointed out in the
>> first response, probably more trouble than its worth.
>>>
>>> Mark
>>>
>>>
>>>
>>>
>>> On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote:
>>>
>>>> Do you have practical examples that either are not
>> supported, or the actual
>>>> ordering is the contrary than you expected?
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Mark Derricutt <ma...@talios.com>.
I've been meaning to check out the clirr-plugin - I'll add that to my TODO reading list for the morning.
On 1/08/2011, at 12:15 AM, Mark Struberg wrote:
> PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin.
Re: Pluggable Dependency Resolution
Posted by Mark Struberg <st...@yahoo.de>.
I thought about that too, and actually don't think that there is a general solution.
Two examples:
* JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new getParentLogger() method. To compile your own DataSource with java7 you need to implement this method. It is perfectly compatible to get executed on java5 and 6 too, so what you need is the latest version of the dependency (JDBC-4.1) while compiling your project. If you get invoked as a callback or similar, it's a good idea to implement the widest possible range.
* The story turns around if you act as a client invoking other libs. If interfaces you use in your projects got extended with new methods in a new version, then this will obviously not work together with older lib versions once you made use of the new methods. In this case you should restrict yourself to the subset of methods available in all versions of the lib.
Plus, there are lots of grey tones between those 2 scenarios. E.g. if some method parameter or config tag expresses version and capability...
LieGrue,
strub
PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin.
--- On Sun, 7/31/11, Jason van Zyl <ja...@sonatype.com> wrote:
> From: Jason van Zyl <ja...@sonatype.com>
> Subject: Re: Pluggable Dependency Resolution
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Sunday, July 31, 2011, 11:58 AM
> What if you could find another way to
> check API compatibility, would you need this at all?
>
> On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote:
>
> > The use case that we originally came with in our
> discussions revolved around version ranges, and the fact
> that a version reference of "2.5.4" doesn't actually mean "
> give me 2.5.4" but rather "I would like 2.5.4, but meh, use
> something higher if you need to".
> >
> > In the case were you have artifacts using say
> [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will
> favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1,
> and 2.5.0 are available, maven will choose 1.6.0 to compile
> against.
> >
> > What we were discussing was that ideally you'd to
> compile against the lowest lower bound ( 1.5.1 ), this way
> you'd get fail fast on any changed APIs that you
> inadvertently started to use, alerting you to the fact that
> you need to increment the lower bound of your range.
> >
> > If you require bug fixes in a newer release which is
> triggering your tests to fail, then you should also be
> incrementing the lower bound.
> >
> > The whole purpose of this flow is to drive you to
> releasing often, and working off binary dependencies rather
> than long standing -SNAPSHOTs. This flow would seem to
> work best for places who are releasing artifacts every 2-3
> days, and working in a continuous delivery style process -
> it probably wouldn't work for Apache projects which often
> seem to favor long drawn out cycles ( I recall a thread
> awhile ago about not wanting to release a plugin cause it
> only had one bug fix in it ).
> >
> >
> > Having read the other comments I realize my initial
> idea is a little crazy, and as Jason pointed out in the
> first response, probably more trouble than its worth.
> >
> > Mark
> >
> >
> >
> >
> > On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote:
> >
> >> Do you have practical examples that either are not
> supported, or the actual
> >> ordering is the contrary than you expected?
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Jason van Zyl <ja...@sonatype.com>.
What if you could find another way to check API compatibility, would you need this at all?
On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote:
> The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of "2.5.4" doesn't actually mean " give me 2.5.4" but rather "I would like 2.5.4, but meh, use something higher if you need to".
>
> In the case were you have artifacts using say [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1, and 2.5.0 are available, maven will choose 1.6.0 to compile against.
>
> What we were discussing was that ideally you'd to compile against the lowest lower bound ( 1.5.1 ), this way you'd get fail fast on any changed APIs that you inadvertently started to use, alerting you to the fact that you need to increment the lower bound of your range.
>
> If you require bug fixes in a newer release which is triggering your tests to fail, then you should also be incrementing the lower bound.
>
> The whole purpose of this flow is to drive you to releasing often, and working off binary dependencies rather than long standing -SNAPSHOTs. This flow would seem to work best for places who are releasing artifacts every 2-3 days, and working in a continuous delivery style process - it probably wouldn't work for Apache projects which often seem to favor long drawn out cycles ( I recall a thread awhile ago about not wanting to release a plugin cause it only had one bug fix in it ).
>
>
> Having read the other comments I realize my initial idea is a little crazy, and as Jason pointed out in the first response, probably more trouble than its worth.
>
> Mark
>
>
>
>
> On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote:
>
>> Do you have practical examples that either are not supported, or the actual
>> ordering is the contrary than you expected?
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Pluggable Dependency Resolution
Posted by Mark Derricutt <ma...@talios.com>.
The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of "2.5.4" doesn't actually mean " give me 2.5.4" but rather "I would like 2.5.4, but meh, use something higher if you need to".
In the case were you have artifacts using say [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1, and 2.5.0 are available, maven will choose 1.6.0 to compile against.
What we were discussing was that ideally you'd to compile against the lowest lower bound ( 1.5.1 ), this way you'd get fail fast on any changed APIs that you inadvertently started to use, alerting you to the fact that you need to increment the lower bound of your range.
If you require bug fixes in a newer release which is triggering your tests to fail, then you should also be incrementing the lower bound.
The whole purpose of this flow is to drive you to releasing often, and working off binary dependencies rather than long standing -SNAPSHOTs. This flow would seem to work best for places who are releasing artifacts every 2-3 days, and working in a continuous delivery style process - it probably wouldn't work for Apache projects which often seem to favor long drawn out cycles ( I recall a thread awhile ago about not wanting to release a plugin cause it only had one bug fix in it ).
Having read the other comments I realize my initial idea is a little crazy, and as Jason pointed out in the first response, probably more trouble than its worth.
Mark
On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote:
> Do you have practical examples that either are not supported, or the actual
> ordering is the contrary than you expected?
Re: Pluggable Dependency Resolution
Posted by Hervé BOUTEMY <he...@free.fr>.
I see this one regularly and don't frankly understand the need other than pure
theory.
Actual version comparison supports every numbering scheme I ever saw in
reality. The only choice that has been made that is a pure choice (neither
good nor bad, just a choice had to be made) is that unknown qualifiers are
considered after known ones [1].
Do you have practical examples that either are not supported, or the actual
ordering is the contrary than you expected?
I'm really interested, because in the first case, I need to add support for
something new, but only the second needs a pluggable version comparison
algorithm
Then if we really need this one, we'll have the problem of *where* we should
configure the value: project-level is a nightmare if ever really possible, CLI
doesn't make sense IMHO, then we have user-level or install level
But even at user or install level, I doubt this will be usable
Regards,
Hervé
[1] http://maven.apache.org/ref/3.0.4-
SNAPSHOT/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
Le dimanche 31 juillet 2011, Stephen Connolly a écrit :
> oh i forgot to mention. i also think that version comparison rules should
> be plugable.
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 31 Jul 2011 08:27, "Stephen Connolly" <st...@gmail.com>
>
> wrote:
> > i see two concerns that need separation.
> >
> > 1. the code that fetches dependencies from wherever they live.
> >
> > 2. the code that computed the dependencies graph.
> >
> > #1 should be something that is plugable, and in essence could be part of
>
> the
>
> > repositories definitions... in saying that, i think we need a way to
> > separate the current project build infrastructure from the fixed
>
> information
>
> > inherent in tagging the codebase for a release. the projects repositories
> > and issue tracker, are things which can evolve over time, and having them
> > fixed in an immutable pom is bad for users. if we can find some way of
> > fixing that concern then that would be a good thing.
> >
> > #2 is a different beast. i think forcing the osgi scheme on users is bad
>
> for
>
> > users. i could be selfish and say that i no longer work for a telecom
> > company that insists on 5-6 segment version numbers (depends on how you
> > choose to release as to whether one of those segments applies) but
> > forcing
>
> 4
>
> > segments on those users is wrong. i don't mind making life a little
> > harder for people venturing away from maven's opinionated view, but
> > forcing
>
> people
>
> > to conform to get full functionality is bad for users. where this all
> > fits in is defining which versions fall within a defined range, and how
> > to
>
> choose
>
> > a version from within that range.
> >
> > iirc osgi does allow hinting in regard for which end of the range to
>
> favour,
>
> > but because of its classloading isolation, there is less of a problem for
> > osgi. osgi being designed to solve the 2 dependencies needing conflicting
> > versions of the same dependency problem.
> >
> > i am more willing to view #2 as being something that we should be looking
> > into not being plugable, but instead allow hints to the impl to say which
> > end of the range to favour... closest hint wins (sort of)
> >
> > however we do need a clear separation between exposing that as a maven
> > api and whatever code we have solving that graph for us.
> >
> > - Stephen
> >
> > ---
> > Sent from my Android phone, so random spelling mistakes, random nonsense
> > words and other nonsense are a direct result of using swype to type on
> > the screen
> > On 31 Jul 2011 07:41, "Mark Struberg" <st...@yahoo.de> wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Stephen Connolly <st...@gmail.com>.
oh i forgot to mention. i also think that version comparison rules should be
plugable.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Jul 2011 08:27, "Stephen Connolly" <st...@gmail.com>
wrote:
> i see two concerns that need separation.
>
> 1. the code that fetches dependencies from wherever they live.
>
> 2. the code that computed the dependencies graph.
>
> #1 should be something that is plugable, and in essence could be part of
the
> repositories definitions... in saying that, i think we need a way to
> separate the current project build infrastructure from the fixed
information
> inherent in tagging the codebase for a release. the projects repositories
> and issue tracker, are things which can evolve over time, and having them
> fixed in an immutable pom is bad for users. if we can find some way of
> fixing that concern then that would be a good thing.
>
> #2 is a different beast. i think forcing the osgi scheme on users is bad
for
> users. i could be selfish and say that i no longer work for a telecom
> company that insists on 5-6 segment version numbers (depends on how you
> choose to release as to whether one of those segments applies) but forcing
4
> segments on those users is wrong. i don't mind making life a little harder
> for people venturing away from maven's opinionated view, but forcing
people
> to conform to get full functionality is bad for users. where this all fits
> in is defining which versions fall within a defined range, and how to
choose
> a version from within that range.
>
> iirc osgi does allow hinting in regard for which end of the range to
favour,
> but because of its classloading isolation, there is less of a problem for
> osgi. osgi being designed to solve the 2 dependencies needing conflicting
> versions of the same dependency problem.
>
> i am more willing to view #2 as being something that we should be looking
> into not being plugable, but instead allow hints to the impl to say which
> end of the range to favour... closest hint wins (sort of)
>
> however we do need a clear separation between exposing that as a maven api
> and whatever code we have solving that graph for us.
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 31 Jul 2011 07:41, "Mark Struberg" <st...@yahoo.de> wrote:
Re: Pluggable Dependency Resolution
Posted by Jason van Zyl <ja...@sonatype.com>.
On Jul 31, 2011, at 3:27 AM, Stephen Connolly wrote:
> i see two concerns that need separation.
>
> 1. the code that fetches dependencies from wherever they live.
>
Sure, I've known people to change this in many ways. Integration of legacy artifact stores, migration strategies which involve pulling things from SCMs or what have you. Lots of people have modified this that I know of. This can happen in many ways and hasn't done anything too terrible in the places I've seen it implemented.
> 2. the code that computed the dependencies graph.
>
Right, the specification and interpretation of a version scheme happening in multiple ways I think would be highly problematic. I don't really see much upside to making this pluggable.
> #1 should be something that is plugable, and in essence could be part of the
> repositories definitions... in saying that, i think we need a way to
> separate the current project build infrastructure from the fixed information
> inherent in tagging the codebase for a release. the projects repositories
> and issue tracker, are things which can evolve over time, and having them
> fixed in an immutable pom is bad for users. if we can find some way of
> fixing that concern then that would be a good thing.
>
> #2 is a different beast. i think forcing the osgi scheme on users is bad for
> users. i could be selfish and say that i no longer work for a telecom
> company that insists on 5-6 segment version numbers (depends on how you
> choose to release as to whether one of those segments applies) but forcing 4
> segments on those users is wrong. i don't mind making life a little harder
> for people venturing away from maven's opinionated view, but forcing people
> to conform to get full functionality is bad for users. where this all fits
> in is defining which versions fall within a defined range, and how to choose
> a version from within that range.
>
> iirc osgi does allow hinting in regard for which end of the range to favour,
> but because of its classloading isolation, there is less of a problem for
> osgi. osgi being designed to solve the 2 dependencies needing conflicting
> versions of the same dependency problem.
>
> i am more willing to view #2 as being something that we should be looking
> into not being plugable, but instead allow hints to the impl to say which
> end of the range to favour... closest hint wins (sort of)
>
> however we do need a clear separation between exposing that as a maven api
> and whatever code we have solving that graph for us.
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 31 Jul 2011 07:41, "Mark Struberg" <st...@yahoo.de> wrote:
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
Re: Pluggable Dependency Resolution
Posted by Mark Struberg <st...@yahoo.de>.
agree.
The OSGi naming schema makes it easier to detect if a version is higher or lower than another. But the trade off is numerous, let alone compatibility with the versions of already existing maven artifacts.
LieGrue,
strub
Just as a side note: The handling of multiple jars in different versions in OSGi sounds cool in theory, but in practice it tends to make your system unstable. This really only works if the dependencies form an unidirectional directed graph and you need to recompile all dependencies downwards or you don't change any public APIs.
Just upgrade Eclipse a few times and you see what I mean. After max 10 upgrades, your Eclipse installation is completely messed up as you _will_ get conflicting dependencies which don't work together nicely.
--- On Sun, 7/31/11, Stephen Connolly <st...@gmail.com> wrote:
> From: Stephen Connolly <st...@gmail.com>
> Subject: Re: Pluggable Dependency Resolution
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Sunday, July 31, 2011, 7:27 AM
> i see two concerns that need
> separation.
>
> 1. the code that fetches dependencies from wherever they
> live.
>
> 2. the code that computed the dependencies graph.
>
> #1 should be something that is plugable, and in essence
> could be part of the
> repositories definitions... in saying that, i think we need
> a way to
> separate the current project build infrastructure from the
> fixed information
> inherent in tagging the codebase for a release. the
> projects repositories
> and issue tracker, are things which can evolve over time,
> and having them
> fixed in an immutable pom is bad for users. if we can find
> some way of
> fixing that concern then that would be a good thing.
>
> #2 is a different beast. i think forcing the osgi scheme on
> users is bad for
> users. i could be selfish and say that i no longer work for
> a telecom
> company that insists on 5-6 segment version numbers
> (depends on how you
> choose to release as to whether one of those segments
> applies) but forcing 4
> segments on those users is wrong. i don't mind making life
> a little harder
> for people venturing away from maven's opinionated view,
> but forcing people
> to conform to get full functionality is bad for users.
> where this all fits
> in is defining which versions fall within a defined range,
> and how to choose
> a version from within that range.
>
> iirc osgi does allow hinting in regard for which end of the
> range to favour,
> but because of its classloading isolation, there is less of
> a problem for
> osgi. osgi being designed to solve the 2 dependencies
> needing conflicting
> versions of the same dependency problem.
>
> i am more willing to view #2 as being something that we
> should be looking
> into not being plugable, but instead allow hints to the
> impl to say which
> end of the range to favour... closest hint wins (sort of)
>
> however we do need a clear separation between exposing that
> as a maven api
> and whatever code we have solving that graph for us.
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes,
> random nonsense
> words and other nonsense are a direct result of using swype
> to type on the
> screen
> On 31 Jul 2011 07:41, "Mark Struberg" <st...@yahoo.de>
> wrote:
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Stephen Connolly <st...@gmail.com>.
i see two concerns that need separation.
1. the code that fetches dependencies from wherever they live.
2. the code that computed the dependencies graph.
#1 should be something that is plugable, and in essence could be part of the
repositories definitions... in saying that, i think we need a way to
separate the current project build infrastructure from the fixed information
inherent in tagging the codebase for a release. the projects repositories
and issue tracker, are things which can evolve over time, and having them
fixed in an immutable pom is bad for users. if we can find some way of
fixing that concern then that would be a good thing.
#2 is a different beast. i think forcing the osgi scheme on users is bad for
users. i could be selfish and say that i no longer work for a telecom
company that insists on 5-6 segment version numbers (depends on how you
choose to release as to whether one of those segments applies) but forcing 4
segments on those users is wrong. i don't mind making life a little harder
for people venturing away from maven's opinionated view, but forcing people
to conform to get full functionality is bad for users. where this all fits
in is defining which versions fall within a defined range, and how to choose
a version from within that range.
iirc osgi does allow hinting in regard for which end of the range to favour,
but because of its classloading isolation, there is less of a problem for
osgi. osgi being designed to solve the 2 dependencies needing conflicting
versions of the same dependency problem.
i am more willing to view #2 as being something that we should be looking
into not being plugable, but instead allow hints to the impl to say which
end of the range to favour... closest hint wins (sort of)
however we do need a clear separation between exposing that as a maven api
and whatever code we have solving that graph for us.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Jul 2011 07:41, "Mark Struberg" <st...@yahoo.de> wrote:
Re: Pluggable Dependency Resolution
Posted by Mark Struberg <st...@yahoo.de>.
Jason, behaviour != implementation !
If someone likes to store his artifacts in a database or taking it from a p4, why not?
And actually having a much cleaner interface on our side would be highly welcome!
LieGrue,
strub
--- On Sat, 7/30/11, Jason van Zyl <ja...@sonatype.com> wrote:
> From: Jason van Zyl <ja...@sonatype.com>
> Subject: Re: Pluggable Dependency Resolution
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Saturday, July 30, 2011, 11:58 PM
> 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.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Pluggable Dependency Resolution
Posted by Jason van Zyl <ja...@sonatype.com>.
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.