Hi, I was interested in the below thread wrt to the deprecation of LATEST , RELEASE etc.
There is a ref http://docs.codehaus.org/display/MAVEN/Versioning on https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-VersionComparison I registered myself on the wiki and did a bit of digging and found the following page https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning Would it be correct and or useful to update the above codehaus ref on https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-VersionComparison to point to https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning ? Kind regards, Robert Kielty -----Original Message----- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: 11 April 2017 22:57 To: Maven Users List Subject: Re: dependency question Hi, On 11/04/17 23:38, Stephen Connolly wrote: > On Tue 11 Apr 2017 at 20:55, Curtis Rueden <ctrue...@wisc.edu> wrote: > >> Hi Stephen, >> >>>> There is a special version keyword LATEST which means the very >>>> newest version, snapshot or otherwise. And RELEASE means the newest >>>> release >>>> (non-SNAPSHOT) version. >>> >>> Support for those were dropped in Maven 3 >> >> By "support" do you mean "social support" as opposed to technical >> functionality? > > > They were supposed to be removed. > > If they are working now, that's a bug Unfortunately they are working ;-(.. https://issues.apache.org/jira/browse/MNG-6206 Kind regards Karl Heinz Marbaise > > >> >> Because they are still present in the codebase, and they still work >> technically: >> https://github.com/apache/maven/blob/master/maven- >> resolver-provider/src/main/java/org/apache/maven/repository/internal/ >> DefaultVersionResolver.java#L188-L197 >> >> Regards, >> Curtis >> >> -- >> Curtis Rueden >> LOCI software architect - https://loci.wisc.edu/software >> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden >> >> >> On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >>> On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote: >>> >>>> Hi Hector, >>>> >>>>> This is fine as long as the dependency is always set to >> x.y.z-Snapshot >>>>> and the dependency is always overwritten this way. What if the >>>>> producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, >> x.y.z.3-Snapshot >>>>> and I want the dependent build to always get the latest in this >>>>> case, x.y.z.3-Snapshot ? >>>> >>>> There is a special version keyword LATEST which means the very >>>> newest version, snapshot or otherwise. And RELEASE means the newest >>>> release >>>> (non-SNAPSHOT) version. >>> >>> >>> Support for those were dropped in Maven 3 >>> >>> *and* anyway they were only for *plugin* versions because the plugin >>> version does not support ranges. >>> >>> For dependency versions, define a range >>> >>>> >>>> >>>> Similar to version ranges, Maven will have to ask the remote >>>> repository about the latest known version in these cases, and will then >>>> use that. >>>> >>>> I want to emphasize, as others have mentioned, that using any of >>>> these strategies will result in _irreproducible builds_. That is, >>>> your code >>> might >>>> build today, and then the same code will fail to build in the >>>> future, because the versions will resolve differently. The only way >>>> (I know of) >>> to >>>> achieve reproducible builds is to use fixed release versions, always. >>>> >>>> Regards, >>>> Curtis >>>> >>>> -- >>>> Curtis Rueden >>>> LOCI software architect - https://loci.wisc.edu/software >>>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden >>>> >>>> >>>> On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector < >>> hector.magna...@sap.com >>>>> >>>> wrote: >>>> >>>>> This is fine as long as the dependency is always set to >> x.y.z-Snapshot >>>> and >>>>> the dependency is always overwritten this way. What if the >>>>> producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, >>>>> x.y.z.3-Snapshot and I >>> want >>>>> the dependent build to always get the latest in this case, >>>>> x.y.z.3-Snapshot ? The difference with this scenario is that the >>> producer >>>>> will always have a new build number. >>>>> As for your solution of using the range, do I always have to >>>>> change >>> the >>>>> pom file in the dependent build whenever a new build is produced >>>>> by >> the >>>>> producer ? >>>>> >>>>> -----Original Message----- >>>>> From: Benson Margulies [mailto:bimargul...@gmail.com] >>>>> Sent: Monday, April 10, 2017 10:39 AM >>>>> To: Maven Users List <users@maven.apache.org> >>>>> Subject: Re: dependency question >>>>> >>>>> On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector >>>>> <hector.magna...@sap.com> wrote: >>>>>> I'm still a little confused about the answers I'm getting. So, >>>>>> if >>>> build >>>>> A is being updated with a new build number(even for a snapshot), >>>>> and >>>> build >>>>> B has it as a dependency in it's pom.file, how does the pom file >>>>> in >>>> Build B >>>>> need to look like in the dependency section so that it does get >>>>> the >>>> latest >>>>> snapshot build of build A ? >>>>> >>>>> This conversation seems to keep mixing up SNAPSHOT version >>>>> processing with various conventions for using version ranges. >>>>> >>>>> If the producer produces x.y.z-SNAPSHOT, and the consumer declares >>>>> a dependency on x.y.z-SNAPSHOT, every build of the consumer will >>>>> go out to the repositories to look for the latest snapshot build. >>>>> >>>>> Snapshots have risks and do not provide a repeatable build. Then >>>>> again, neither do ranges. >>>>> >>>>> If you don't want to use snapshots, then you write the dependency >>>>> in the consumer with a range >>>>> >>>>> (1.0-2.0] >>>>> >>>>> or whatever makes sense. This will cause builds of the consumer to >>>>> go out to repositories and try to find the newest version within >>>>> the range. it's up to you to bump the version in the producer, >>>>> manually >> or >>>>> with the maven-release-plugin. >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Scenario: >>>>>> >>>>>> Build A has 3 builds in it with names 1-Snapshot, 2-snapshot, >>>> 3-snapshot >>>>> and they are all being uploaded to a repository. >>>>>> >>>>>> What will the pom file in build B look like so that the next time >>> build >>>>> B is executed, 3-snapshot for build A will be picked up ? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] >>>>>> Sent: Friday, April 7, 2017 10:50 AM >>>>>> To: Maven Users List <users@maven.apache.org> >>>>>> Subject: Re: dependency question >>>>>> >>>>>> Hi Russlel, >>>>>> On 07/04/17 17:29, Russell Gold wrote: >>>>>> >>>>>>> That’s the way it works: when you specify a snapshot, it takes >>>>>>> the >>>>> latest. >>>>>> >>>>>> This is not 100% true, cause it depends on the update policy you >> have >>>>>> defined in your settings either explicit or by default the >>>>>> updates >>> will >>>>>> be checked every 24 hours... >>>>>> >>>>>> If you like to force this you can use mvn -U ...or define a >> different >>>>>> updatePolicy in your settings.xml for the appropriate repository. >>>>>> >>>>>> By using mvn -U you make sure for running this build Maven will >> check >>>> if >>>>>> there are newer SNAPSHOT version available for dependencies which >>> have >>>>>> defined a SNAPSHOT version.... >>>>>> >>>>>> This is working for a single module project...but if you have a >> multi >>>>>> module build (Project C: A1 build before A2) which takes for >> example >>> 5 >>>>>> minutes to build ...this is no longer 100% true... >>>>>> >>>>>> Now let us assume you have another project B which dependends on >> two >>>>>> different artifacts (A1, A2) of Project C ...this means in >>> consequence >>>>>> those artifacts are build at two different times... >>>>>> >>>>>> This means it could happen that your build of Project B consumes >>>>>> A2 >>>> from >>>>>> build #10 but A1 from build #9 ... >>>>>> >>>>>> >>>>>> In practical it usually works without any issue using the mvn -U >>> ...but >>>>>> you should be aware of this issue... >>>>>> >>>>>> >>>>>> The only solution which I have found to make 100% sure is to use >> the >>>>>> output during the build of the project A and use those parsed >>>>>> informations about the SNAPSHOT versions and inject them into my >>>> current >>>>>> build ...(https://github.com/khmarbaise/deployment-recorder- >>> extension >>>>>> not ready yet)... >>>>>> >>>>>> Kind regards >>>>>> Karl Heinz Marbaise >>>>>> >>>>>> >>>>>>> >>>>>>> There are some corner cases where it won’t. I think it only >>>>>>> checks >>> for >>>>> a new snapshot every few hours or so, so if you are putting out a >>>>> lot >>> you >>>>> might conceivably miss one. You can reset that if you need to >>>>>>> . >>>>>>>> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector < >>>> hector.magna...@sap.com> >>>>> wrote: >>>>>>>> >>>>>>>> If the builds for A are always getting a unique build number as >>>>>>>> a >>>>> snapshot build, how am I sure that B will always get the latest >>> snapshot >>>>> of A ? Is there a way to name the A snapshot builds with a unique >>> build >>>>> number each time for this scenario. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Russell Gold [mailto:russell.g...@oracle.com] >>>>>>>> Sent: Thursday, April 6, 2017 2:27 PM >>>>>>>> To: Maven Users List <users@maven.apache.org> >>>>>>>> Subject: Re: dependency question >>>>>>>> >>>>>>>> The simplest way is simply to use a snapshot version of A. That >>> way B >>>>> will always use the latest snapshot. When you finally release A, >>>>> you >>> can >>>>> have B point to the released version instead of the snapshot. >>>>>>>> >>>>>>>>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector < >>>> hector.magna...@sap.com> >>>>> wrote: >>>>>>>>> >>>>>>>>> I have to 2 java projects a and b in maven. The B project >>>>>>>>> uses >>> the >>>> A >>>>> build as a dependency. How do I ensure the whenever the A project >> has >>> a >>>>> new build, the B project will always use that latest build in A. >>>>> A >> is >>>>> being built with a unique build number each time it gets built. >>>>> So >> is >>> A >>>>> has build # 10 as the newest build, the B project has to use >>>>> build >> #10 >>>> of >>>>> A. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hector Magnanao Jr. >>>>>>>>> SCM Analyst >>>>>>>>> SAP Fieldglass >>>>>>>>> Skype: (331) 702-6142 >>>>>>>>> Mobile: (847) 857-8401 >>>>>>>>> Email: hector.magna...@sap.com >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This document is strictly confidential and is intended for use by the addressee unless otherwise indicated. Allied Irish Banks AIB and AIB Group are registered business names of Allied Irish Banks p.l.c. Allied Irish Banks, p.l.c. is regulated by the Central Bank of Ireland. Registered Office: Bankcentre, Ballsbridge, Dublin 4. Tel: + 353 1 6600311; Registered in Ireland: Registered No. 24173. ~~~~~~~Please consider the environment before printing this Email~~~~~~~~ This email has been scanned by an external Email Security System. This Disclaimer has been generated by CMDis
