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 PM, 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 PM 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 (AT) mpsa (DOT) com
To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.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

08/11/05, fabrice.belingard (AT) mpsa (DOT) com <fabrice.belingard (AT) mpsa (DOT) comwrote:
>
>
>
>
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 PM, 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 PM 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 (AT) mpsa (DOT) com
--

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
--

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

08/11/05, Jason van Zyl <jason (AT) maven (DOT) orgwrote:
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:

And the code appears to be:

Looks like a bit of work to implement another strategy.

Mark

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

Hi Fabrice,

08/11/05, fabrice.belingard (AT) mpsa (DOT) com <fabrice.belingard (AT) mpsa (DOT) comwrote:
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 (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

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 (
).

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 PM 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. IM, 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 PM 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 == 11.4)
* A depends on this range of versions of B (say B >= 1.0 && B < 2.0)

Thanks in advance for any feedback.

Roger

11/8/05, Mark Hobson <markhobson (AT) gmail (DOT) comwrote:

Hi Fabrice,

08/11/05, fabrice.belingard (AT) mpsa (DOT) com <fabrice.belingard (AT) mpsa (DOT) 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 (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
--

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.

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

11/9/05, Roger Hoover <roger.hoover (AT) gmail (DOT) comwrote:
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 (
).

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 PM 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. IM, 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 PM 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

11/8/05, Mark Hobson <markhobson (AT) gmail (DOT) comwrote:

Hi Fabrice,

08/11/05, fabrice.belingard (AT) mpsa (DOT) com <fabrice.belingard (AT) mpsa (DOT) 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 (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
>
>
>
>

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org

Thanks, Brett. I think this is the document you're refering to.

11/8/05, Brett Porter <brett.porter (AT) gmail (DOT) comwrote:

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.

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.orgthat explains the range
syntax.

Hope this helps,
Brett

11/9/05, Roger Hoover <roger.hoover (AT) gmail (DOT) comwrote:
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 (
).

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 PM 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. IM, 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 PM 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

11/8/05, Mark Hobson <markhobson (AT) gmail (DOT) comwrote:

Hi Fabrice,

08/11/05, fabrice.belingard (AT) mpsa (DOT) com <fabrice.belingard (AT) mpsa (DOT) 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 (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
>
>
>
>
>

To unsubscribe, e-mail: users-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: users-help (AT) maven (DOT) apache.org
--