Hi Christian, On 18/10/2007, Christian Weber <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
