[
https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466593#comment-17466593
]
Curtis Rueden edited comment on MNG-7343 at 12/29/21, 8:57 PM:
---------------------------------------------------------------
> 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.
was (Author: ctrueden):
> 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)
