[
https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466593#comment-17466593
]
Curtis Rueden commented on MNG-7343:
------------------------------------
> Can you share concrete other examples, please?
Sure! Here is one use case:
[https://github.com/scijava/jgo#readme]
The jgo tool lets you launch Java code from remote Maven artifacts. For
example, you can run:
jgo org.python:jython-standalone
to launch the latest release version of the Jython REPL. Or:
jgo ome:bio-formats-tools:loci.formats.tools.ImageConverter
to launch the latest release version of the
[Bio-Formats|https://www.openmicroscopy.org/bio-formats/] image conversion
tool. Or:
jgo com.github.kwart.jd:jd-cli
for the latest release version of the
[jd-cli|https://github.com/intoolswetrust/jd-cli] decompiler. Or:
jgo sc.fiji:fiji
for the latest release version of [Fiji|https://fiji.sc/].
All of the above examples implicitly use the `RELEASE` metaversion. While the
user can also specify an explicit version, often what they want is the latest
release, and jgo using `RELEASE` by default is very convenient. It would be
possible to replicate this behavior by digging through remote
`maven-metadata.xml` files, or using MojoHaus's versions-maven-plugin, but this
would add extra code and complexity, extra remote negotiation with every jgo
execution, and corresponding potential for extra bugs.
> And wan you precise which Jira issue is causing you that reaction?
I'm sorry, I don't understand the question. Are you asking if there is a Jira
issue corresponding to my statement: "in my tests, specifying a version range
like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?) versions
of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en masse
downloading."? Unfortunately, there is not a corresponding issue, as far as I
know. I could file one if it would be helpful.
> Document a working migration path away from LATEST and RELEASE metaversions
> ---------------------------------------------------------------------------
>
> Key: MNG-7343
> URL: https://issues.apache.org/jira/browse/MNG-7343
> Project: Maven
> Issue Type: Bug
> Reporter: Curtis Rueden
> Priority: Major
>
> I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that
> automatically synthesizes POMs to perform various tasks. I personally feel
> deprecating these metaversions was a mistake—I find them incredibly useful,
> with the understanding that I would never use them for production
> reproducible builds. But I do understand the rationale: we don't want to
> encourage anyone to use these in a way that harms the stability of dependency
> resolution, reproducibility-wise. So I'm OK with it, as long as there is a
> migration path forward for these sorts of use cases.
> But what is that path? I cannot find a way to replicate either of the
> metaversion behaviors using version ranges. There are problems with version
> ranges (MNG-3092, MNG-6049) preventing them from being used as a replacement
> for LATEST or RELEASE. Furthermore, in my tests, specifying a version range
> like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?)
> versions of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en
> masse downloading.l
> Is there a non-deprecated syntax that has equivalent behavior? As things
> stand, I am concerned that support for these metaversions is going to
> disappear in a future version of Maven without a feasible migration path
> forward.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
