[jira] [Comment Edited] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[ https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466712#comment-17466712 ] Herve Boutemy edited comment on MNG-7343 at 12/30/21, 7:43 AM: --- thanks for the details about jgo IIUC, it runs "mvn dependency:resolve" against a generated pom.xml that defines dependencies usually using RELEASE and LATEST meta-versions https://github.com/scijava/jgo/blob/master/jgo/jgo.py#L626 you write: bq. I personally feel deprecating these metaversions was a mistake can you point to the deprecation that was done? was (Author: hboutemy): thanks for the details about jgo IIUC, it runs "mvn dependency:resolve" against a generated pom.xml that defines dependencies usually using RELEASE and LATEST meta-versions https://github.com/scijava/jgo/blob/master/jgo/jgo.py#L626 you write: bq. I personally feel deprecating these metaversions was a mistake can you point to the deprecation that was done and how it is causing you issues? > 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)
[jira] [Comment Edited] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[ https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466712#comment-17466712 ] Herve Boutemy edited comment on MNG-7343 at 12/30/21, 7:42 AM: --- thanks for the details about jgo IIUC, it runs "mvn dependency:resolve" against a generated pom.xml that defines dependencies usually using RELEASE and LATEST meta-versions https://github.com/scijava/jgo/blob/master/jgo/jgo.py#L626 you write: bq. I personally feel deprecating these metaversions was a mistake can you point to the deprecation that was done and how it is causing you issues? was (Author: hboutemy): thanks for the details about jgo IIUC, it runs "mvn dependency:resolve" against a generated pom.xml that defines dependencies usually using RELEASE and LATEST meta-versions you write: bq. I personally feel deprecating these metaversions was a mistake can you point to the deprecation that was done and how it is causing you issues? > 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)
[jira] [Comment Edited] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[ https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466712#comment-17466712 ] Herve Boutemy edited comment on MNG-7343 at 12/30/21, 7:40 AM: --- thanks for the details about jgo IIUC, it runs "mvn dependency:resolve" against a generated pom.xml that defines dependencies usually using RELEASE and LATEST meta-versions you write: bq. I personally feel deprecating these metaversions was a mistake can you point to the deprecation that was done and how it is causing you issues? was (Author: hboutemy): thanks for the details about jgo you write: bq. I personally feel deprecating these metaversions was a mistake can you point to the deprecation that was done and how it is causing you issues? > 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)
[jira] [Comment Edited] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[ https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466712#comment-17466712 ] Herve Boutemy edited comment on MNG-7343 at 12/30/21, 7:34 AM: --- thanks for the details about jgo you write: bq. I personally feel deprecating these metaversions was a mistake can you point to the deprecation that was done and how it is causing you issues? was (Author: hboutemy): thanks for the details about jgo you write: bq. I personally feel deprecating these metaversions was a mistake can you point to the deprecation that is causing you issues? > 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)
[jira] [Comment Edited] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[ 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, M