Curtis,
For what it's worth, I completely agree. This is a broken part of Maven
that we've learned to work around because of a theoretical benefit. I
can agree with needing to specify a version or version range for other
dependencies, but for my code in non-Prod environments -- I want
LATEST. Always.
I looked into this about three(?) years ago and it looked a bit like a
religious battle, so I just declared defeat. I think there was a ticket
created that was closed "Won't Fix".
We have Nexus rebuild it's metadata for the affected repositories and
this adjusts the LATEST tag.
I started coding an optional parameter for Maven to be used locally and
I think the code's 90% there, but I had a series of problems using Maven
to build Maven and had to do other work and never got back to it.
On 04/24/2017 11:58 AM, Curtis Rueden wrote:
I would like to argue for the inclusion / restoration / continued
support of the RELEASE and LATEST tags.
Really? No one else cares enough to respond?
I am very often running into use cases where the easiest solution seems to
be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM
and I need to know things like "which components have new releases
available" and "which components have SNAPSHOT builds since the last
release." How do other people answer these questions without custom
tooling, and without using LATEST or RELEASE tags?
Regards,
Curtis
--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden <ctrue...@wisc.edu> wrote:
Hi Maven developers,
I would like to argue for the inclusion / restoration / continued support
of the RELEASE and LATEST tags.
Reasons:
1) There are many valid use cases for them. For example, my script jrun
[1] uses RELEASE right now to make it easier to launch a Maven GAV.
Launching e.g. the Jython REPL is as easy as "jrun
org.python:jython-standalone" from the CLI. But this relies on RELEASE
working. I know that Maven is traditionally viewed as primarily a
build-time tool, but it is also extremely useful for synthesizing runtime
environments, and IMHO underutilized in this regard.
2) For LATEST, you can achieve basically the same behavior using a version
range like [0,). There is no other way (that I know of) to achieve what the
RELEASE tag does.
3) The argument that they harm reproducibility is totally valid. But so do
SNAPSHOTs, and so do version ranges. And those have not been deprecated. So
why are RELEASE and LATEST eschewed so heavily?
Orthogonally: I think it would be awesome to warn about irreproducible
builds, be they from SNAPSHOTs, version ranges, or these special keywords.
People need to know when their builds are vulnerable. But there should
probably also be a property to disable this warning, for the cases when the
developer intentionally wants/needs to use them, and knows what they are
doing. If the issue is just that no ones has time to work on e.g. MNG-6206,
I could try to make some time for it—I feel strongly enough about this
issue.
Thanks for any insight, workarounds, counterarguments, agreement.
(Especially if you agree: please speak up, so the core Maven devs know I'm
not just an outlier here!)
Regards,
Curtis
[1] https://github.com/ctrueden/jrun
--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
--
Rick Huff, Principal Software Engineer
Identity and Access Management Team
ITS Applications, The University of Texas at Austin
