You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Christian Weber <CW...@DIaLOGIKa.de> on 2007/10/18 19:42:04 UTC
Version Ranges & Dependency Conflicts
Hi all,
i'm using Maven + Artifactory to manage my Java Projects. Which worked fine so far.
But now i'm running into Problem with the Dependency Resolving.
I have different Versions of a LibA, e.g.:
LibA-1.4.13.9
LibA-1.4.13.55
Now, in my App "AppA", i always want to use the newest Version of LibA. So i set the Range of the Dependency of LibA to [1.4.13.1,1.4.13.100].
As Result i get LibA-1.4.13.9 instead of the newer LibA-1.4.13.55.
After searching around and testing, it seems, that the 4. Digit ( 9 and 55 ) are compared as String not as Numbers, so that 9 is greater than 55.
Unfortuneatly this destroys the Dependency Solving in this Case.
I found out, that the standard Maven Version Number is build as follows: <Number>.<Number>.<Number>-<String>-<Number>
But i need something like <Number>.<Number>.<Number>.<Number>-<String>-<Number>
Is there a Possibility to specify, either per Projects (pom.xml) or per Machine (settings.xml) or somehowelse, how a Version Number should look like
is it further possible to plug in an own Comparsion Class, which shall be used to compare 2 Versions and decide, which one is newer?
Another Problem, reported to me by Colleagues, is the Following:
I have a App "AppA" again, which needs 2 Libs "LibA" & "LibB":
AppA
|- LibA
|- LibB
Both Libs now need the same LibC.
Szenario 1:
AppA
|- LibA
| - LibC 1.4.0.7
|- LibB
| - LibC 1.4.0.15
If i compile this Project it successes by choosing one Version of LibC according to my Colleagues, although it should have failed because no common Version is available, which suffices 1.4.0.7 and at the same time 1.4.0.15.
How can i solve this?
My last Question is about the Policy of Choosing a the Version of a Lib.
Szenario 2:
AppA
|- LibA
| - LibC [1.4.0.7,1.4.0.15]
|- LibB
| - LibC [1.4.0.4,1.4.0.13]
With the standard Policy, the newest common Version is choosen, as far as i understand. So in "Szenario 2", LibC-1.4.0.13 is choosen.
Is it also possible to instruct Maven to always choose the oldest common Version, so that in "Szenario 2", LibC-1.4.0.7 is choosen?
This Way it is much more suitable for testing, because i can reproduce a specific Build, no matter how many new Version are released in the Meantime.
Let me explain, why i need this
Szenario 3:
AppA
|- LibA
| - LibC [1.4.0.9,)
|- LibB
| - LibC [1.4.0.8,)
Let's say, that i've tested my Programm AppA with LibC 1.4.0.8 2 Days ago and the Build was successfull.
One Day ago a new Version of LibC was released, Version 1.5.0.0.
If i now start the same Build Process, it will most problably fail.
If Maven would always have choosen the oldest matching Version, the Build will succeed assuming that i didn't change AppA.
This would be the Szenario of Testing a specific Build and deploying it some Days later.
Kind Regards,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Version Ranges & Dependency Conflicts
Posted by Mark Hobson <ma...@gmail.com>.
Hi Christian,
On 18/10/2007, Christian Weber <CW...@dialogika.de> wrote:
> i'm using Maven + Artifactory to manage my Java Projects. Which worked fine so far.
> But now i'm running into Problem with the Dependency Resolving.
>
> I have different Versions of a LibA, e.g.:
> LibA-1.4.13.9
> LibA-1.4.13.55
>
> Now, in my App "AppA", i always want to use the newest Version of LibA. So i set the Range of the Dependency of LibA to [1.4.13.1,1.4.13.100].
> As Result i get LibA-1.4.13.9 instead of the newer LibA-1.4.13.55.
>
> After searching around and testing, it seems, that the 4. Digit ( 9 and 55 ) are compared as String not as Numbers, so that 9 is greater than 55.
> Unfortuneatly this destroys the Dependency Solving in this Case.
>
> I found out, that the standard Maven Version Number is build as follows: <Number>.<Number>.<Number>-<String>-<Number>
>
> But i need something like <Number>.<Number>.<Number>.<Number>-<String>-<Number>
>
> Is there a Possibility to specify, either per Projects (pom.xml) or per Machine (settings.xml) or somehowelse, how a Version Number should look like
> is it further possible to plug in an own Comparsion Class, which shall be used to compare 2 Versions and decide, which one is newer?
Unfortunately not at the moment, but Kenney produced a proposal for
improving this in future:
http://docs.codehaus.org/display/MAVEN/Versioning
> Another Problem, reported to me by Colleagues, is the Following:
>
> I have a App "AppA" again, which needs 2 Libs "LibA" & "LibB":
> AppA
> |- LibA
> |- LibB
>
> Both Libs now need the same LibC.
>
> Szenario 1:
> AppA
> |- LibA
> | - LibC 1.4.0.7
> |- LibB
> | - LibC 1.4.0.15
>
>
> If i compile this Project it successes by choosing one Version of LibC according to my Colleagues, although it should have failed because no common Version is available, which suffices 1.4.0.7 and at the same time 1.4.0.15.
> How can i solve this?
Maven would pick the first version it encounters if they are of equal
depth in the dependency tree. To enforce version 1.4.0.7 only, and
fail the build in the above example, use the 'hard version' syntax
[1.4.0.7]. For more information, see:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
> My last Question is about the Policy of Choosing a the Version of a Lib.
>
> Szenario 2:
> AppA
> |- LibA
> | - LibC [1.4.0.7,1.4.0.15]
> |- LibB
> | - LibC [1.4.0.4,1.4.0.13]
>
> With the standard Policy, the newest common Version is choosen, as far as i understand. So in "Szenario 2", LibC-1.4.0.13 is choosen.
> Is it also possible to instruct Maven to always choose the oldest common Version, so that in "Szenario 2", LibC-1.4.0.7 is choosen?
Unfortunately not, this is currently hardcoded to pick the newest
common version in VersionRange.matchVersion. I agree this should be
configurable but am not aware of a raised issue for this? Do raise
one if you can't find one.
By the way, there's a related issue MNG-612 that provides alternative
conflict resolvers for dependency conflicts, although this doesn't
extend to resolving version ranges something similar would be
required.
> This Way it is much more suitable for testing, because i can reproduce a specific Build, no matter how many new Version are released in the Meantime.
>
> Let me explain, why i need this
> Szenario 3:
> AppA
> |- LibA
> | - LibC [1.4.0.9,)
> |- LibB
> | - LibC [1.4.0.8,)
> Let's say, that i've tested my Programm AppA with LibC 1.4.0.8 2 Days ago and the Build was successfull.
> One Day ago a new Version of LibC was released, Version 1.5.0.0.
> If i now start the same Build Process, it will most problably fail.
> If Maven would always have choosen the oldest matching Version, the Build will succeed assuming that i didn't change AppA.
> This would be the Szenario of Testing a specific Build and deploying it some Days later.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Version Ranges & Dependency Conflicts
Posted by Wayne Fay <wa...@gmail.com>.
The idea of "configurable versioning" has been discussed as a future
addition, but it is a complex issue and is certainly not available at
this time, so you will need to convert your usage of versions to match
what Maven expects/demands.
Wayne
On 10/18/07, dhoffer <DH...@xrite.com> wrote:
>
> I don't know if you can override maven's standard version number, but I have
> my doubts. I suggest you change your policy and go with maven's versioning,
> this is likely to be less trouble in the end.
>
> See comments below...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Version Ranges & Dependency Conflicts
Posted by dhoffer <DH...@xrite.com>.
I don't know if you can override maven's standard version number, but I have
my doubts. I suggest you change your policy and go with maven's versioning,
this is likely to be less trouble in the end.
See comments below...
Christian Weber-5 wrote:
>
> Hi all,
>
> i'm using Maven + Artifactory to manage my Java Projects. Which worked
> fine so far.
> But now i'm running into Problem with the Dependency Resolving.
>
> I have different Versions of a LibA, e.g.:
> LibA-1.4.13.9
> LibA-1.4.13.55
>
> Now, in my App "AppA", i always want to use the newest Version of LibA. So
> i set the Range of the Dependency of LibA to [1.4.13.1,1.4.13.100].
> As Result i get LibA-1.4.13.9 instead of the newer LibA-1.4.13.55.
>
> After searching around and testing, it seems, that the 4. Digit ( 9 and 55
> ) are compared as String not as Numbers, so that 9 is greater than 55.
> Unfortuneatly this destroys the Dependency Solving in this Case.
>
> I found out, that the standard Maven Version Number is build as follows:
> <Number>.<Number>.<Number>-<String>-<Number>
>
> But i need something like
> <Number>.<Number>.<Number>.<Number>-<String>-<Number>
>
> Is there a Possibility to specify, either per Projects (pom.xml) or per
> Machine (settings.xml) or somehowelse, how a Version Number should look
> like
> is it further possible to plug in an own Comparsion Class, which shall be
> used to compare 2 Versions and decide, which one is newer?
>
>
>
> Another Problem, reported to me by Colleagues, is the Following:
>
> I have a App "AppA" again, which needs 2 Libs "LibA" & "LibB":
> AppA
> |- LibA
> |- LibB
>
> Both Libs now need the same LibC.
>
> Szenario 1:
> AppA
> |- LibA
> | - LibC 1.4.0.7
> |- LibB
> | - LibC 1.4.0.15
>
>
> If i compile this Project it successes by choosing one Version of LibC
> according to my Colleagues, although it should have failed because no
> common Version is available, which suffices 1.4.0.7 and at the same time
> 1.4.0.15.
> How can i solve this?
>
> - Not sure I understand...if you have a common dependency why not factor
> it out and put the version you want in the parent pom?
>
>
> My last Question is about the Policy of Choosing a the Version of a Lib.
>
> Szenario 2:
> AppA
> |- LibA
> | - LibC [1.4.0.7,1.4.0.15]
> |- LibB
> | - LibC [1.4.0.4,1.4.0.13]
>
> With the standard Policy, the newest common Version is choosen, as far as
> i understand. So in "Szenario 2", LibC-1.4.0.13 is choosen.
> Is it also possible to instruct Maven to always choose the oldest common
> Version, so that in "Szenario 2", LibC-1.4.0.7 is choosen?
>
> - No, version ranges mean use the latest valid version.
>
>
> This Way it is much more suitable for testing, because i can reproduce a
> specific Build, no matter how many new Version are released in the
> Meantime.
>
> - Don't use version ranges if you don't want the version to change, rather
> pin it to the version you want.
>
>
> Let me explain, why i need this
> Szenario 3:
> AppA
> |- LibA
> | - LibC [1.4.0.9,)
> |- LibB
> | - LibC [1.4.0.8,)
> Let's say, that i've tested my Programm AppA with LibC 1.4.0.8 2 Days ago
> and the Build was successfull.
> One Day ago a new Version of LibC was released, Version 1.5.0.0.
> If i now start the same Build Process, it will most problably fail.
> If Maven would always have choosen the oldest matching Version, the Build
> will succeed assuming that i didn't change AppA.
> This would be the Szenario of Testing a specific Build and deploying it
> some Days later.
>
> Kind Regards,
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-Ranges---Dependency-Conflicts-tf4648724s177.html#a13287194
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org