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?

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
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> >
> --
> Sent from my phone
>

Reply via email to