You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by fa...@mpsa.com on 2005/11/08 11:47:45 UTC
[m2] How dependency versions are resolved with transitivity?
Hi,
Does anyone know how Maven resolves a version for a specific depedency when
this dependency comes with different versions due to transitivity?
I have the following case: I'm developing a framework where I use
commons-lang version 2.0, along with other libs that have commons-lang in
their POM, but with a different version (1.0.1 most of the time). In my
WAR, I end up with version 1.0.1 of commons-lang.
I know that projects using my framework can handle that by using dependency
management. However, I would expect that version 2.0 of commons-lang would
be used as I specified it in the deps of the POM of my framework (shouldn't
that "override" the version 1.0.1 given by transitivity of other libs ?).
Thanks for you answer !
Best Regards / Cordialement,
Fabrice BELLINGARD
DINQ/DSIN/INSI/EATE/IDVS/AIDV
(+33) (01 61) 45 15 91 - fabrice.belingard@mpsa.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] How dependency versions are resolved with transitivity?
Posted by Mark Hobson <ma...@gmail.com>.
On 08/11/05, Jason van Zyl <ja...@maven.org> wrote:
> > As a side note, I really need the highest-wins strategy - any pointers
> > to open issues or code required?
>
> It's slated for 2.1.
Right thanks. Just found the issue if anyone's interested:
http://jira.codehaus.org/browse/MNG-612
And the code appears to be:
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/ArtifactCollector.java?rev=279720&view=markup
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java?rev=330201&view=markup
Looks like a bit of work to implement another strategy.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] How dependency versions are resolved with transitivity?
Posted by Jason van Zyl <ja...@maven.org>.
On Tue, 2005-11-08 at 12:49 +0000, Mark Hobson wrote:
> Hi Fabrice,
>
> mvn currently mediates dependency versions using a nearest-wins
> strategy. This means that the dependency version specified highest in
> the dependency tree (i.e. nearest to the project being built) is used.
>
> As a side note, I really need the highest-wins strategy - any pointers
> to open issues or code required?
It's slated for 2.1.
> Mark
>
> On 08/11/05, fabrice.belingard@mpsa.com <fa...@mpsa.com> wrote:
> >
> >
> >
> >
> > Hi,
> >
> > Does anyone know how Maven resolves a version for a specific depedency when
> > this dependency comes with different versions due to transitivity?
> >
> > I have the following case: I'm developing a framework where I use
> > commons-lang version 2.0, along with other libs that have commons-lang in
> > their POM, but with a different version (1.0.1 most of the time). In my
> > WAR, I end up with version 1.0.1 of commons-lang.
> > I know that projects using my framework can handle that by using dependency
> > management. However, I would expect that version 2.0 of commons-lang would
> > be used as I specified it in the deps of the POM of my framework (shouldn't
> > that "override" the version 1.0.1 given by transitivity of other libs ?).
> >
> > Thanks for you answer !
> >
> > Best Regards / Cordialement,
> > Fabrice BELLINGARD
> > DINQ/DSIN/INSI/EATE/IDVS/AIDV
> > (+33) (01 61) 45 15 91 - fabrice.belingard@mpsa.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] How dependency versions are resolved with transitivity?
Posted by Roger Hoover <ro...@gmail.com>.
Thanks, Brett. I think this is the document you're refering to.
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
On 11/8/05, Brett Porter <br...@gmail.com> wrote:
>
> The default in Maven 2.0 is to use "soft versions", ie if you say
> "2.0.2", you are recommending, but not enforcing, that version.
>
> You can instead give a range such as [1.0,2.0) - this is a hard
> requirement. To force a specific version, you can say [2.0.2,2.0.2].
>
> If two dependencies have mutually exclusive ranges, the resolution
> fails with an error.
>
> Once all ranges are taken into account, the conflict resolver comes
> into play. In Maven 2.0, the only resolver is "nearest" - so the soft
> version in the pom nearest in the graph is used. If there is no soft
> version in any of the dependencies (ie, they are all ranges), the
> newest (ie, highest upper bound) is used.
>
> In Maven 2.1, we plan to add new conflict resolvers. This only missed
> 2.0 by the narrowest of margins - which was a shame as it is almost
> there and "newest" resolution was in fact the default in an earlier
> alpha but caused much confusion. So other resolvers would be to use
> the newest, oldest, nearest (like now), or just fail if there is more
> than one recommendation.
>
> While the documentation is still pending, there is a design document
> on docs.codehaus.org <http://docs.codehaus.org> that explains the range
> syntax.
>
> Hope this helps,
> Brett
>
> On 11/9/05, Roger Hoover <ro...@gmail.com> wrote:
> > My understanding is that Maven 2 supports a syntax for specifying a
> range of
> > versions in a dependency. What is the syntax for this? I searched the
> Maven
> > site and found only a link saying documentation was needed for it (
> > http://maven.apache.org/maven2/docs-required.html).
> >
> > Will transitive dependencies with incompatible version ranges resolve
> > successfully or cause an error? I assume an error would result as
> expected
> > in the following scenario where A depends on both B and C, which have
> > incompatible range dependencies on D.
> >
> > A -> B -> (D > 3.0)
> > -> C -> (D < 2.0)
> >
> > Correct me if I'm wrong in my assumptions about how Maven 2 works. My
> > understanding is based off of reading this thread. If I understand
> correctly
> > then I find the dependency resolution strategy unintuitive for the
> following
> > reasons:
> >
> > 1) The non-range dependency syntax requires an explicit version to be
> > specified but treats it like a range when it's involved in transitive
> > resolution. In Fabrice's example, his framework POM declared an explicit
> > dependency on commons-lang 2.0 but Maven treated that dependency like a
> > range specification (the range of all versions) such that any version
> would
> > satisfy that dependency without error. Here we have an explicit version
> > syntax with the semantics of the range of all versions. IMO, Fabrice's
> > example should have caused an error b/c these explicit dependency
> versions
> > are incompatible. In general, how can you be sure that any version of a
> > package will do when the author of the POM specified a particular
> version?
> >
> > 2) If transitive resolution behaves the way you'd expect for version
> ranges
> > and gives an error in the example I gave above, then you would expect
> > explicit version dependencies to just be special cases of ranges (they
> are
> > range sets of size one). Therefore, you would expect an error in
> Fabrice's
> > example again b/c his framework has a range dependency on commons-lang
> > 2.0where the range happens to include only one version. Likewise, the
> > other lib
> > that uses commons-lang has a range dependency on 1.0.1. These are
> > non-overlapping ranges.
> >
> > I may be misunderstanding the current Maven 2 behavior but if not then I
> > think Maven needs a more intuitive syntax. There needs to be a clear way
> of
> > expressing the following statements
> > * A depends on any version of B
> > * A depends on this specific version of B and only this version (B ==
> 1.1.4)
> > * A depends on this range of versions of B (say B >= 1.0 && B < 2.0)
> >
> > Thanks in advance for any feedback.
> >
> > Roger
> >
> > On 11/8/05, Mark Hobson <ma...@gmail.com> wrote:
> > >
> > > Hi Fabrice,
> > >
> > > On 08/11/05, fabrice.belingard@mpsa.com <fa...@mpsa.com>
> > > wrote:
> > > > Hi Mark,
> > > >
> > > > Thank you for your answer! :)
> > >
> > > No probs.
> > >
> > > > Then I have another question: when 2 different dependency versions
> are
> > > at
> > > > the same level in the dependency tree, which one wins? Because in my
> > > case,
> > > > I have version 2.0 and version 1.0.1 of commons-lang at the same
> level,
> > > and
> > > > 1.0.1 wins.
> > >
> > > Not sure, I know I have had problems with this before. I currently
> > > fix these uncertainties with an overriding dependency version in my
> > > top-level pom, but agree that's nasty. Have a look through the
> > > DefaultArtifactCollector code (see the link in my previous reply) and
> > > see if you can deduce what it does.
> > >
> > > > The highest-win strategy would be interesting, I agree.
> > >
> > > I would like to look into implementing this before 2.1 if I can find
> > > the time (probably not then ;).
> > >
> > > Cheers,
> > >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] How dependency versions are resolved with transitivity?
Posted by Brett Porter <br...@gmail.com>.
The default in Maven 2.0 is to use "soft versions", ie if you say
"2.0.2", you are recommending, but not enforcing, that version.
You can instead give a range such as [1.0,2.0) - this is a hard
requirement. To force a specific version, you can say [2.0.2,2.0.2].
If two dependencies have mutually exclusive ranges, the resolution
fails with an error.
Once all ranges are taken into account, the conflict resolver comes
into play. In Maven 2.0, the only resolver is "nearest" - so the soft
version in the pom nearest in the graph is used. If there is no soft
version in any of the dependencies (ie, they are all ranges), the
newest (ie, highest upper bound) is used.
In Maven 2.1, we plan to add new conflict resolvers. This only missed
2.0 by the narrowest of margins - which was a shame as it is almost
there and "newest" resolution was in fact the default in an earlier
alpha but caused much confusion. So other resolvers would be to use
the newest, oldest, nearest (like now), or just fail if there is more
than one recommendation.
While the documentation is still pending, there is a design document
on docs.codehaus.org that explains the range syntax.
Hope this helps,
Brett
On 11/9/05, Roger Hoover <ro...@gmail.com> wrote:
> My understanding is that Maven 2 supports a syntax for specifying a range of
> versions in a dependency. What is the syntax for this? I searched the Maven
> site and found only a link saying documentation was needed for it (
> http://maven.apache.org/maven2/docs-required.html).
>
> Will transitive dependencies with incompatible version ranges resolve
> successfully or cause an error? I assume an error would result as expected
> in the following scenario where A depends on both B and C, which have
> incompatible range dependencies on D.
>
> A -> B -> (D > 3.0)
> -> C -> (D < 2.0)
>
> Correct me if I'm wrong in my assumptions about how Maven 2 works. My
> understanding is based off of reading this thread. If I understand correctly
> then I find the dependency resolution strategy unintuitive for the following
> reasons:
>
> 1) The non-range dependency syntax requires an explicit version to be
> specified but treats it like a range when it's involved in transitive
> resolution. In Fabrice's example, his framework POM declared an explicit
> dependency on commons-lang 2.0 but Maven treated that dependency like a
> range specification (the range of all versions) such that any version would
> satisfy that dependency without error. Here we have an explicit version
> syntax with the semantics of the range of all versions. IMO, Fabrice's
> example should have caused an error b/c these explicit dependency versions
> are incompatible. In general, how can you be sure that any version of a
> package will do when the author of the POM specified a particular version?
>
> 2) If transitive resolution behaves the way you'd expect for version ranges
> and gives an error in the example I gave above, then you would expect
> explicit version dependencies to just be special cases of ranges (they are
> range sets of size one). Therefore, you would expect an error in Fabrice's
> example again b/c his framework has a range dependency on commons-lang
> 2.0where the range happens to include only one version. Likewise, the
> other lib
> that uses commons-lang has a range dependency on 1.0.1. These are
> non-overlapping ranges.
>
> I may be misunderstanding the current Maven 2 behavior but if not then I
> think Maven needs a more intuitive syntax. There needs to be a clear way of
> expressing the following statements
> * A depends on any version of B
> * A depends on this specific version of B and only this version (B == 1.1.4)
> * A depends on this range of versions of B (say B >= 1.0 && B < 2.0)
>
> Thanks in advance for any feedback.
>
> Roger
>
> On 11/8/05, Mark Hobson <ma...@gmail.com> wrote:
> >
> > Hi Fabrice,
> >
> > On 08/11/05, fabrice.belingard@mpsa.com <fa...@mpsa.com>
> > wrote:
> > > Hi Mark,
> > >
> > > Thank you for your answer! :)
> >
> > No probs.
> >
> > > Then I have another question: when 2 different dependency versions are
> > at
> > > the same level in the dependency tree, which one wins? Because in my
> > case,
> > > I have version 2.0 and version 1.0.1 of commons-lang at the same level,
> > and
> > > 1.0.1 wins.
> >
> > Not sure, I know I have had problems with this before. I currently
> > fix these uncertainties with an overriding dependency version in my
> > top-level pom, but agree that's nasty. Have a look through the
> > DefaultArtifactCollector code (see the link in my previous reply) and
> > see if you can deduce what it does.
> >
> > > The highest-win strategy would be interesting, I agree.
> >
> > I would like to look into implementing this before 2.1 if I can find
> > the time (probably not then ;).
> >
> > Cheers,
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] How dependency versions are resolved with transitivity?
Posted by Roger Hoover <ro...@gmail.com>.
My understanding is that Maven 2 supports a syntax for specifying a range of
versions in a dependency. What is the syntax for this? I searched the Maven
site and found only a link saying documentation was needed for it (
http://maven.apache.org/maven2/docs-required.html).
Will transitive dependencies with incompatible version ranges resolve
successfully or cause an error? I assume an error would result as expected
in the following scenario where A depends on both B and C, which have
incompatible range dependencies on D.
A -> B -> (D > 3.0)
-> C -> (D < 2.0)
Correct me if I'm wrong in my assumptions about how Maven 2 works. My
understanding is based off of reading this thread. If I understand correctly
then I find the dependency resolution strategy unintuitive for the following
reasons:
1) The non-range dependency syntax requires an explicit version to be
specified but treats it like a range when it's involved in transitive
resolution. In Fabrice's example, his framework POM declared an explicit
dependency on commons-lang 2.0 but Maven treated that dependency like a
range specification (the range of all versions) such that any version would
satisfy that dependency without error. Here we have an explicit version
syntax with the semantics of the range of all versions. IMO, Fabrice's
example should have caused an error b/c these explicit dependency versions
are incompatible. In general, how can you be sure that any version of a
package will do when the author of the POM specified a particular version?
2) If transitive resolution behaves the way you'd expect for version ranges
and gives an error in the example I gave above, then you would expect
explicit version dependencies to just be special cases of ranges (they are
range sets of size one). Therefore, you would expect an error in Fabrice's
example again b/c his framework has a range dependency on commons-lang
2.0where the range happens to include only one version. Likewise, the
other lib
that uses commons-lang has a range dependency on 1.0.1. These are
non-overlapping ranges.
I may be misunderstanding the current Maven 2 behavior but if not then I
think Maven needs a more intuitive syntax. There needs to be a clear way of
expressing the following statements
* A depends on any version of B
* A depends on this specific version of B and only this version (B == 1.1.4)
* A depends on this range of versions of B (say B >= 1.0 && B < 2.0)
Thanks in advance for any feedback.
Roger
On 11/8/05, Mark Hobson <ma...@gmail.com> wrote:
>
> Hi Fabrice,
>
> On 08/11/05, fabrice.belingard@mpsa.com <fa...@mpsa.com>
> wrote:
> > Hi Mark,
> >
> > Thank you for your answer! :)
>
> No probs.
>
> > Then I have another question: when 2 different dependency versions are
> at
> > the same level in the dependency tree, which one wins? Because in my
> case,
> > I have version 2.0 and version 1.0.1 of commons-lang at the same level,
> and
> > 1.0.1 wins.
>
> Not sure, I know I have had problems with this before. I currently
> fix these uncertainties with an overriding dependency version in my
> top-level pom, but agree that's nasty. Have a look through the
> DefaultArtifactCollector code (see the link in my previous reply) and
> see if you can deduce what it does.
>
> > The highest-win strategy would be interesting, I agree.
>
> I would like to look into implementing this before 2.1 if I can find
> the time (probably not then ;).
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] How dependency versions are resolved with transitivity?
Posted by Mark Hobson <ma...@gmail.com>.
Hi Fabrice,
On 08/11/05, fabrice.belingard@mpsa.com <fa...@mpsa.com> wrote:
> Hi Mark,
>
> Thank you for your answer! :)
No probs.
> Then I have another question: when 2 different dependency versions are at
> the same level in the dependency tree, which one wins? Because in my case,
> I have version 2.0 and version 1.0.1 of commons-lang at the same level, and
> 1.0.1 wins.
Not sure, I know I have had problems with this before. I currently
fix these uncertainties with an overriding dependency version in my
top-level pom, but agree that's nasty. Have a look through the
DefaultArtifactCollector code (see the link in my previous reply) and
see if you can deduce what it does.
> The highest-win strategy would be interesting, I agree.
I would like to look into implementing this before 2.1 if I can find
the time (probably not then ;).
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] How dependency versions are resolved with transitivity?
Posted by fa...@mpsa.com.
Hi Mark,
Thank you for your answer! :)
Then I have another question: when 2 different dependency versions are at
the same level in the dependency tree, which one wins? Because in my case,
I have version 2.0 and version 1.0.1 of commons-lang at the same level, and
1.0.1 wins.
The highest-win strategy would be interesting, I agree.
Best Regards / Cordialement,
Fabrice BELLINGARD
DINQ/DSIN/INSI/EATE/IDVS/AIDV
(+33) (01 61) 45 15 91 - fabrice.belingard@mpsa.com
Mark Hobson
<markhobson@gmai
l.com> Pour
Maven Users List
08/11/2005 13:49 <us...@maven.apache.org>
cc
Veuillez Objet
répondre à Re: [m2] How dependency versions
Maven Users List are resolved with transitivity?
<users@maven.apa
che.org>
Hi Fabrice,
mvn currently mediates dependency versions using a nearest-wins
strategy. This means that the dependency version specified highest in
the dependency tree (i.e. nearest to the project being built) is used.
As a side note, I really need the highest-wins strategy - any pointers
to open issues or code required?
Mark
On 08/11/05, fabrice.belingard@mpsa.com <fa...@mpsa.com> wrote:
>
>
>
>
> Hi,
>
> Does anyone know how Maven resolves a version for a specific depedency
when
> this dependency comes with different versions due to transitivity?
>
> I have the following case: I'm developing a framework where I use
> commons-lang version 2.0, along with other libs that have commons-lang in
> their POM, but with a different version (1.0.1 most of the time). In my
> WAR, I end up with version 1.0.1 of commons-lang.
> I know that projects using my framework can handle that by using
dependency
> management. However, I would expect that version 2.0 of commons-lang
would
> be used as I specified it in the deps of the POM of my framework
(shouldn't
> that "override" the version 1.0.1 given by transitivity of other libs ?).
>
> Thanks for you answer !
>
> Best Regards / Cordialement,
> Fabrice BELLINGARD
> DINQ/DSIN/INSI/EATE/IDVS/AIDV
> (+33) (01 61) 45 15 91 - fabrice.belingard@mpsa.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] How dependency versions are resolved with transitivity?
Posted by Mark Hobson <ma...@gmail.com>.
Hi Fabrice,
mvn currently mediates dependency versions using a nearest-wins
strategy. This means that the dependency version specified highest in
the dependency tree (i.e. nearest to the project being built) is used.
As a side note, I really need the highest-wins strategy - any pointers
to open issues or code required?
Mark
On 08/11/05, fabrice.belingard@mpsa.com <fa...@mpsa.com> wrote:
>
>
>
>
> Hi,
>
> Does anyone know how Maven resolves a version for a specific depedency when
> this dependency comes with different versions due to transitivity?
>
> I have the following case: I'm developing a framework where I use
> commons-lang version 2.0, along with other libs that have commons-lang in
> their POM, but with a different version (1.0.1 most of the time). In my
> WAR, I end up with version 1.0.1 of commons-lang.
> I know that projects using my framework can handle that by using dependency
> management. However, I would expect that version 2.0 of commons-lang would
> be used as I specified it in the deps of the POM of my framework (shouldn't
> that "override" the version 1.0.1 given by transitivity of other libs ?).
>
> Thanks for you answer !
>
> Best Regards / Cordialement,
> Fabrice BELLINGARD
> DINQ/DSIN/INSI/EATE/IDVS/AIDV
> (+33) (01 61) 45 15 91 - fabrice.belingard@mpsa.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org