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

Reply via email to