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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
