On Tue 11 Apr 2017 at 20:55, Curtis Rueden <[email protected]> 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 > > 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 < > [email protected]> wrote: > > > On Tue 11 Apr 2017 at 16:02, Curtis Rueden <[email protected]> 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 < > > [email protected] > > > > > > > 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:[email protected]] > > > > Sent: Monday, April 10, 2017 10:39 AM > > > > To: Maven Users List <[email protected]> > > > > Subject: Re: dependency question > > > > > > > > On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector > > > > <[email protected]> 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:[email protected]] > > > > > Sent: Friday, April 7, 2017 10:50 AM > > > > > To: Maven Users List <[email protected]> > > > > > 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 < > > > [email protected]> > > > > 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:[email protected]] > > > > >>> Sent: Thursday, April 6, 2017 2:27 PM > > > > >>> To: Maven Users List <[email protected]> > > > > >>> 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 < > > > [email protected]> > > > > 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: [email protected] > > > > >>>> > > > > >>> > > > > >>> > > > > > > > > > > ------------------------------------------------------------ > > --------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > -- > > Sent from my phone > > > -- Sent from my phone
