[jira] [Comment Edited] (MWRAPPER-110) The Maven 3.9 `MAVEN_ARGS` env var is not supported
[ https://issues.apache.org/jira/browse/MWRAPPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827744#comment-17827744 ] Tamas Cservenak edited comment on MWRAPPER-110 at 3/16/24 11:30 PM: I recommend making "script-only" the default, as I am using ONLY it and makes sense... Created MWRAPPER-125 was (Author: cstamas): I recommend making "script-only" the default, as I am using ONLY it and makes sense... > The Maven 3.9 `MAVEN_ARGS` env var is not supported > --- > > Key: MWRAPPER-110 > URL: https://issues.apache.org/jira/browse/MWRAPPER-110 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.2.0 >Reporter: Dimitar Dimitrov >Priority: Major > > If we specify arguments in `MAVEN_ARGS`, they are picked up automatically by > `mvn`, but not by `mvnw`. > Please port this patch: [https://github.com/apache/maven/pull/49] > A workaround is to export an extra env variable `MAVEN_CONFIG` which is > picked by `mvnw` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-125) Make "script-only" the default wrapper
Tamas Cservenak created MWRAPPER-125: Summary: Make "script-only" the default wrapper Key: MWRAPPER-125 URL: https://issues.apache.org/jira/browse/MWRAPPER-125 Project: Maven Wrapper Issue Type: Improvement Components: Maven Wrapper Plugin Reporter: Tamas Cservenak As it really delegates to "proper" maven, no magic, no fuss. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-110) The Maven 3.9 `MAVEN_ARGS` env var is not supported
[ https://issues.apache.org/jira/browse/MWRAPPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827744#comment-17827744 ] Tamas Cservenak commented on MWRAPPER-110: -- I recommend making "script-only" the default, as I am using ONLY it and makes sense... > The Maven 3.9 `MAVEN_ARGS` env var is not supported > --- > > Key: MWRAPPER-110 > URL: https://issues.apache.org/jira/browse/MWRAPPER-110 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.2.0 >Reporter: Dimitar Dimitrov >Priority: Major > > If we specify arguments in `MAVEN_ARGS`, they are picked up automatically by > `mvn`, but not by `mvnw`. > Please port this patch: [https://github.com/apache/maven/pull/49] > A workaround is to export an extra env variable `MAVEN_CONFIG` which is > picked by `mvnw` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-110) The Maven 3.9 `MAVEN_ARGS` env var is not supported
[ https://issues.apache.org/jira/browse/MWRAPPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827743#comment-17827743 ] Damiano Albani commented on MWRAPPER-110: - Thanks [~sjaranowski], this is indeed a solution. > The Maven 3.9 `MAVEN_ARGS` env var is not supported > --- > > Key: MWRAPPER-110 > URL: https://issues.apache.org/jira/browse/MWRAPPER-110 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.2.0 >Reporter: Dimitar Dimitrov >Priority: Major > > If we specify arguments in `MAVEN_ARGS`, they are picked up automatically by > `mvn`, but not by `mvnw`. > Please port this patch: [https://github.com/apache/maven/pull/49] > A workaround is to export an extra env variable `MAVEN_CONFIG` which is > picked by `mvnw` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-62) Build-Jdk in Manifest.mf does not reflect which compiler version actually compiled the classes in the jar
[
https://issues.apache.org/jira/browse/MJAR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827740#comment-17827740
]
Jorge Solórzano commented on MJAR-62:
-
[~sjaranowski] Yes, the *Build-Jdk* entry is more like an _extension_ of Maven
added to the Manifest.
> Build-Jdk in Manifest.mf does not reflect which compiler version actually
> compiled the classes in the jar
> -
>
> Key: MJAR-62
> URL: https://issues.apache.org/jira/browse/MJAR-62
> Project: Maven JAR Plugin
> Issue Type: Bug
>Reporter: Stefan Magnus Landrø
>Priority: Major
> Attachments: example-app.zip
>
>
> Manifest.mf does not reflect the version of the compiler that built the jar,
> but defaults to the version that maven runs under: Build-Jdk:
> ${java.version}.
> I believe this makes users uncertain of which compiler was actually used to
> build the classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Update README.adoc [maven-mvnd]
nathansit commented on code in PR #925: URL: https://github.com/apache/maven-mvnd/pull/925#discussion_r1527227059 ## README.adoc: ## @@ -183,7 +183,7 @@ Properties defined in the first files will take precedence over properties speci A few special properties do not follow the above mechanism: -* `mvnd.daemonStorage`: this property defines the location where mvnd stores its files (registry and daemon logs). This property can only be defined as a system property on the command line +* `mvnd.daemonStorage`: this property defines the location where mvnd stores its files (registry and daemon logs). This property can only be defined as a system property into the command line Review Comment: Aha good catch I must have overwritten and then modified the wrong "on" when I force pushed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1364) AbstractMavenReportRenderer should not depend on Doxia impl classes
[
https://issues.apache.org/jira/browse/MSHARED-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827736#comment-17827736
]
Michael Osipov commented on MSHARED-1364:
-
I see and then extend from to retain binary compat? If so, please create a
ticket and do so.
> AbstractMavenReportRenderer should not depend on Doxia impl classes
> ---
>
> Key: MSHARED-1364
> URL: https://issues.apache.org/jira/browse/MSHARED-1364
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M13
>Reporter: Konrad Windszus
>Priority: Major
>
> The classes in package {{o.a.m.doxia.sink.impl}} should by definition not be
> considered stable API (and therefore only consumed from Doxia classes
> internally).
> However
> {{https://github.com/apache/maven-reporting-impl/blob/72181306bb0e12eed50c4ba4aec98dd76499df39/src/main/java/org/apache/maven/reporting/AbstractMavenReportRenderer.java#L47}}
> depends on some internal constants.
> This is dangerous, as those constants were removed in the context of
> DOXIA-685. Although constants are inlined during compile time, the evaluation
> of those constants vanished as well, so using them has no longer any effect.
> Reporting Impl should only rely on stable Doxia API to achieve a better
> decoupling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8077) artifact plugin should tolerate injected project.build.outputTimestamp
[ https://issues.apache.org/jira/browse/MNG-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827734#comment-17827734 ] ASF GitHub Bot commented on MNG-8077: - rmannibucau opened a new pull request, #30: URL: https://github.com/apache/maven-artifact-plugin/pull/30 (no comment) > artifact plugin should tolerate injected project.build.outputTimestamp > -- > > Key: MNG-8077 > URL: https://issues.apache.org/jira/browse/MNG-8077 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8077) artifact plugin should tolerate injected project.build.outputTimestamp
Romain Manni-Bucau created MNG-8077: --- Summary: artifact plugin should tolerate injected project.build.outputTimestamp Key: MNG-8077 URL: https://issues.apache.org/jira/browse/MNG-8077 Project: Maven Issue Type: Task Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-4840) Prerequisites is not working on m3
[ https://issues.apache.org/jira/browse/MNG-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827728#comment-17827728 ] ASF GitHub Bot commented on MNG-4840: - hboutemy merged PR #1445: URL: https://github.com/apache/maven/pull/1445 > Prerequisites is not working on m3 > -- > > Key: MNG-4840 > URL: https://issues.apache.org/jira/browse/MNG-4840 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1, 3.0-beta-2, > 3.0-beta-3 >Reporter: velo >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0.2 > > Attachments: mng-001.zip, testapp.tar > > > I set my plugin to prerequisite on maven 4 (ok, it doesn't exists yet), but > the build just passed =/ > Sample attached -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-4840] document requiredMavenVersion in plugin descriptor [maven]
hboutemy merged PR #1445: URL: https://github.com/apache/maven/pull/1445 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-4840) Prerequisites is not working on m3
[ https://issues.apache.org/jira/browse/MNG-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827727#comment-17827727 ] ASF GitHub Bot commented on MNG-4840: - hboutemy opened a new pull request, #1445: URL: https://github.com/apache/maven/pull/1445 same as #1444 for Maven 4 > Prerequisites is not working on m3 > -- > > Key: MNG-4840 > URL: https://issues.apache.org/jira/browse/MNG-4840 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1, 3.0-beta-2, > 3.0-beta-3 >Reporter: velo >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0.2 > > Attachments: mng-001.zip, testapp.tar > > > I set my plugin to prerequisite on maven 4 (ok, it doesn't exists yet), but > the build just passed =/ > Sample attached -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1364) AbstractMavenReportRenderer should not depend on Doxia impl classes
[
https://issues.apache.org/jira/browse/MSHARED-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827721#comment-17827721
]
Konrad Windszus commented on MSHARED-1364:
--
I would recommend copy it to
https://github.com/apache/maven-doxia/tree/e01880801ca1283b86205e2f7064b9b4dbc84d54/doxia-sink-api/src/main/java/org/apache/maven/doxia/sink
(and at the same time deprecate the other one).
> AbstractMavenReportRenderer should not depend on Doxia impl classes
> ---
>
> Key: MSHARED-1364
> URL: https://issues.apache.org/jira/browse/MSHARED-1364
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M13
>Reporter: Konrad Windszus
>Priority: Major
>
> The classes in package {{o.a.m.doxia.sink.impl}} should by definition not be
> considered stable API (and therefore only consumed from Doxia classes
> internally).
> However
> {{https://github.com/apache/maven-reporting-impl/blob/72181306bb0e12eed50c4ba4aec98dd76499df39/src/main/java/org/apache/maven/reporting/AbstractMavenReportRenderer.java#L47}}
> depends on some internal constants.
> This is dangerous, as those constants were removed in the context of
> DOXIA-685. Although constants are inlined during compile time, the evaluation
> of those constants vanished as well, so using them has no longer any effect.
> Reporting Impl should only rely on stable Doxia API to achieve a better
> decoupling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump apache/maven-gh-actions-shared from 3 to 4 [maven-invoker-plugin]
slawekjaranowski merged PR #218: URL: https://github.com/apache/maven-invoker-plugin/pull/218 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-62) Build-Jdk in Manifest.mf does not reflect which compiler version actually compiled the classes in the jar
[
https://issues.apache.org/jira/browse/MJAR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827720#comment-17827720
]
Slawomir Jaranowski commented on MJAR-62:
-
There is not specification for *Build-Jdk* entry
https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html
> Build-Jdk in Manifest.mf does not reflect which compiler version actually
> compiled the classes in the jar
> -
>
> Key: MJAR-62
> URL: https://issues.apache.org/jira/browse/MJAR-62
> Project: Maven JAR Plugin
> Issue Type: Bug
>Reporter: Stefan Magnus Landrø
>Priority: Major
> Attachments: example-app.zip
>
>
> Manifest.mf does not reflect the version of the compiler that built the jar,
> but defaults to the version that maven runs under: Build-Jdk:
> ${java.version}.
> I believe this makes users uncertain of which compiler was actually used to
> build the classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-4840) Prerequisites is not working on m3
[ https://issues.apache.org/jira/browse/MNG-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827717#comment-17827717 ] ASF GitHub Bot commented on MNG-4840: - hboutemy merged PR #1444: URL: https://github.com/apache/maven/pull/1444 > Prerequisites is not working on m3 > -- > > Key: MNG-4840 > URL: https://issues.apache.org/jira/browse/MNG-4840 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1, 3.0-beta-2, > 3.0-beta-3 >Reporter: velo >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0.2 > > Attachments: mng-001.zip, testapp.tar > > > I set my plugin to prerequisite on maven 4 (ok, it doesn't exists yet), but > the build just passed =/ > Sample attached -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-4840] document requiredMavenVersion in plugin descriptor [maven]
hboutemy merged PR #1444: URL: https://github.com/apache/maven/pull/1444 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-508) Upgrade to Maven 4.0.0-alpha-12
[ https://issues.apache.org/jira/browse/MPLUGIN-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827716#comment-17827716 ] ASF GitHub Bot commented on MPLUGIN-508: gnodet commented on PR #242: URL: https://github.com/apache/maven-plugin-tools/pull/242#issuecomment-2002027576 > I don't understand the objective? what does "Upgrade to Maven 4.0.0-alpha-12" mean for this plugin that is for Maven 3? can you elaborate, please? The plugin currently supports building either a Maven 3 or a Maven 4 plugin. Though I wonder if a streamlined would be better located inside Maven core... > Upgrade to Maven 4.0.0-alpha-12 > --- > > Key: MPLUGIN-508 > URL: https://issues.apache.org/jira/browse/MPLUGIN-508 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.12.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-508] Upgrade to Maven 4.0.0-alpha-12 [maven-plugin-tools]
gnodet commented on PR #242: URL: https://github.com/apache/maven-plugin-tools/pull/242#issuecomment-2002027576 > I don't understand the objective? what does "Upgrade to Maven 4.0.0-alpha-12" mean for this plugin that is for Maven 3? can you elaborate, please? The plugin currently supports building either a Maven 3 or a Maven 4 plugin. Though I wonder if a streamlined would be better located inside Maven core... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-4840) Prerequisites is not working on m3
[ https://issues.apache.org/jira/browse/MNG-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827707#comment-17827707 ] ASF GitHub Bot commented on MNG-4840: - hboutemy opened a new pull request, #1444: URL: https://github.com/apache/maven/pull/1444 https://issues.apache.org/jira/browse/MNG-4840 but not integrated in documentation until now https://maven.apache.org/ref/3.9.6/maven-plugin-api/plugin.html > Prerequisites is not working on m3 > -- > > Key: MNG-4840 > URL: https://issues.apache.org/jira/browse/MNG-4840 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1, 3.0-beta-2, > 3.0-beta-3 >Reporter: velo >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0.2 > > Attachments: mng-001.zip, testapp.tar > > > I set my plugin to prerequisite on maven 4 (ok, it doesn't exists yet), but > the build just passed =/ > Sample attached -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Document requiredMavenVersion in plugin descriptor (since Maven 3.0.2) [maven]
hboutemy commented on PR #1443: URL: https://github.com/apache/maven/pull/1443#issuecomment-2002013923 wrong target branch... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Document requiredMavenVersion in plugin descriptor (since Maven 3.0.2) [maven]
hboutemy closed pull request #1443: Document requiredMavenVersion in plugin descriptor (since Maven 3.0.2) URL: https://github.com/apache/maven/pull/1443 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-508) Upgrade to Maven 4.0.0-alpha-12
[ https://issues.apache.org/jira/browse/MPLUGIN-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827704#comment-17827704 ] ASF GitHub Bot commented on MPLUGIN-508: hboutemy commented on PR #242: URL: https://github.com/apache/maven-plugin-tools/pull/242#issuecomment-2002000939 I don't understand the objective? what does "Upgrade to Maven 4.0.0-alpha-12" mean for this plugin that is for Maven 3? can you elaborate, please? > Upgrade to Maven 4.0.0-alpha-12 > --- > > Key: MPLUGIN-508 > URL: https://issues.apache.org/jira/browse/MPLUGIN-508 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.12.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-508] Upgrade to Maven 4.0.0-alpha-12 [maven-plugin-tools]
hboutemy commented on PR #242: URL: https://github.com/apache/maven-plugin-tools/pull/242#issuecomment-2002000939 I don't understand the objective? what does "Upgrade to Maven 4.0.0-alpha-12" mean for this plugin that is for Maven 3? can you elaborate, please? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MPLUGIN-510) update plugin system requirements history structure
[ https://issues.apache.org/jira/browse/MPLUGIN-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-510: -- Component/s: Plugin Reporting Plugin (was: Plugin Plugin) > update plugin system requirements history structure > --- > > Key: MPLUGIN-510 > URL: https://issues.apache.org/jira/browse/MPLUGIN-510 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Reporting Plugin >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > in MPLUGIN-400, we added the feature with a list of versions of the plugin, > associated to Maven and JDK prerequisite > https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories > => started to use for example: > [https://maven.apache.org/plugins-archives/maven-assembly-plugin-3.6.0/plugin-info.html] > this lead to questions: should we fill each and every past version? Or should > we group by common prerequisites, showing only ranges? > Tested the range approach: > [https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/plugin-info.html] > the range approach looks good: minimum lines (vs listing every version), > clear choice for users (choose the latest in the range, or pick any > intermediate one) > now, we need to rework the m-p-p configuration to replace "version" with > "from" + "to", instead of hijacking the "version" field to store a String > "from x to y" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-511) create and share tooling to detect plugin prerequisites history
[ https://issues.apache.org/jira/browse/MPLUGIN-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-511: -- Component/s: Plugin Reporting Plugin (was: Plugin Plugin) > create and share tooling to detect plugin prerequisites history > --- > > Key: MPLUGIN-511 > URL: https://issues.apache.org/jira/browse/MPLUGIN-511 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Reporting Plugin >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > to help creating documentation needed on plugins when implementing > MPLUGIN-400, i.e. fill requirementsHistories > [https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories] > > this will be useful both for Maven project itself, because we have 52 plugins > to work on > [https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html] > but this will help also every plugin maintainers: MojoHaus, others -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPLUGIN-511) create and share tooling to detect plugin prerequisites history
[ https://issues.apache.org/jira/browse/MPLUGIN-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPLUGIN-511. - Assignee: Herve Boutemy Resolution: Fixed > create and share tooling to detect plugin prerequisites history > --- > > Key: MPLUGIN-511 > URL: https://issues.apache.org/jira/browse/MPLUGIN-511 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > to help creating documentation needed on plugins when implementing > MPLUGIN-400, i.e. fill requirementsHistories > [https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories] > > this will be useful both for Maven project itself, because we have 52 plugins > to work on > [https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html] > but this will help also every plugin maintainers: MojoHaus, others -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-511) create and share tooling to detect plugin prerequisites history
[ https://issues.apache.org/jira/browse/MPLUGIN-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827703#comment-17827703 ] ASF GitHub Bot commented on MPLUGIN-511: hboutemy merged PR #269: URL: https://github.com/apache/maven-plugin-tools/pull/269 > create and share tooling to detect plugin prerequisites history > --- > > Key: MPLUGIN-511 > URL: https://issues.apache.org/jira/browse/MPLUGIN-511 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > to help creating documentation needed on plugins when implementing > MPLUGIN-400, i.e. fill requirementsHistories > [https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories] > > this will be useful both for Maven project itself, because we have 52 plugins > to work on > [https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html] > but this will help also every plugin maintainers: MojoHaus, others -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] MPLUGIN-511 add plugin requirements history detection [maven-plugin-tools]
hboutemy merged PR #269: URL: https://github.com/apache/maven-plugin-tools/pull/269 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827702#comment-17827702
]
Herve Boutemy commented on MNG-8076:
this does not explain why there is not the "verifying that is downloadable
from" step = what should happen, because the artifact is available if resolver
tried to download it instead of rejecting just because it had been downloaded
before with other repository id
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-501) Upgrade to Doxia 2.0.0 Milestone Stack
[ https://issues.apache.org/jira/browse/MPLUGIN-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827693#comment-17827693 ] Michael Osipov commented on MPLUGIN-501: The how is this related to this issue? I don't understand. The Doxia 2.0.0 branch has all necessary changes. > Upgrade to Doxia 2.0.0 Milestone Stack > -- > > Key: MPLUGIN-501 > URL: https://issues.apache.org/jira/browse/MPLUGIN-501 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > * Upgrade to Doxia 2.0.0-M8 > * Upgrade to Doxia Sitetools 2.0.0-M16 > * Upgrade to Commons Lang 3.14.0 > * Upgrade to Maven Site Plugin 4.0.0-M13 > * Upgrade to Maven Project Info Reports Plugin 4.0.0-M1 > * Upgrade to Plexus Velocity 2.1.0 > * Upgrade to Maven Reporting API 4.0.0-M9 > * Upgrade to Maven Reporting Impl 4.0.0-M13 > * Upgrade to Velocity Engine 2.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DOXIA-731) Simplify HTML emitted from Sink.verbatim(...)
[
https://issues.apache.org/jira/browse/DOXIA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved DOXIA-731.
---
Fix Version/s: 2.0.0
2.0.0-M10
Resolution: Fixed
> Simplify HTML emitted from Sink.verbatim(...)
> -
>
> Key: DOXIA-731
> URL: https://issues.apache.org/jira/browse/DOXIA-731
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0, 2.0.0-M10
>
>
> The XHTML markup generated from Sink.verbatim(...) should be streamlined to
> either emit {{}} or {{}} depending on the given attribute.
> There is no need to generate an additional div nor any additional classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-731) Simplify HTML emitted from Sink.verbatim(...)
[
https://issues.apache.org/jira/browse/DOXIA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827691#comment-17827691
]
ASF GitHub Bot commented on DOXIA-731:
--
kwin merged PR #202:
URL: https://github.com/apache/maven-doxia/pull/202
> Simplify HTML emitted from Sink.verbatim(...)
> -
>
> Key: DOXIA-731
> URL: https://issues.apache.org/jira/browse/DOXIA-731
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The XHTML markup generated from Sink.verbatim(...) should be streamlined to
> either emit {{}} or {{}} depending on the given attribute.
> There is no need to generate an additional div nor any additional classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-731] Simplify HTML markup emitted from Sink.verbatim [maven-doxia]
kwin merged PR #202: URL: https://github.com/apache/maven-doxia/pull/202 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-501) Upgrade to Doxia 2.0.0 Milestone Stack
[ https://issues.apache.org/jira/browse/MPLUGIN-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827690#comment-17827690 ] Konrad Windszus commented on MPLUGIN-501: - This ticket is about Maven Plugin Tools IIUC, which still leverages Doxia 1 (https://github.com/apache/maven-plugin-tools/blob/bf0587c542602fe58259a0658876a9bd6610dc52/maven-plugin-report-plugin/pom.xml#L89) and Reporting Impl/API 3.x (https://github.com/apache/maven-plugin-tools/blob/bf0587c542602fe58259a0658876a9bd6610dc52/pom.xml#L106) > Upgrade to Doxia 2.0.0 Milestone Stack > -- > > Key: MPLUGIN-501 > URL: https://issues.apache.org/jira/browse/MPLUGIN-501 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > * Upgrade to Doxia 2.0.0-M8 > * Upgrade to Doxia Sitetools 2.0.0-M16 > * Upgrade to Commons Lang 3.14.0 > * Upgrade to Maven Site Plugin 4.0.0-M13 > * Upgrade to Maven Project Info Reports Plugin 4.0.0-M1 > * Upgrade to Plexus Velocity 2.1.0 > * Upgrade to Maven Reporting API 4.0.0-M9 > * Upgrade to Maven Reporting Impl 4.0.0-M13 > * Upgrade to Velocity Engine 2.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827689#comment-17827689
]
Tamas Cservenak commented on MNG-8076:
--
Transient release repositories are Maven pet peeve. And staging are such things
(release reposes that come and go). Nota bene: things just get worse when group
repositories are involved, but as I see, this is not the case here.
Am unsure what you want solve with this issue really, as for example if you'd
use split local repository, this issue would be a non-issue really: there,
cached artifacts are kept physically separated from each other (so if
"reference" repository is not in scope, maven would not even find m-shade-p
3.5.2) so would just go and download it.
Problem I see here is more the "reference" repository usage in m-artifact-p:
that remote repository should _never_ use as cache the "main session local
repository" (this is what I always circumvent with -Dmaven.repo.local=... as
noted on prev comment).
Again, the issue you talk about, is maybe non issue at all, as explained above.
Also, seems related, MNG-7802 I guess your env has Central update policy
"never", right?
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Update README.adoc [maven-mvnd]
Stephan202 commented on code in PR #925: URL: https://github.com/apache/maven-mvnd/pull/925#discussion_r1527145248 ## README.adoc: ## @@ -183,7 +183,7 @@ Properties defined in the first files will take precedence over properties speci A few special properties do not follow the above mechanism: -* `mvnd.daemonStorage`: this property defines the location where mvnd stores its files (registry and daemon logs). This property can only be defined as a system property on the command line +* `mvnd.daemonStorage`: this property defines the location where mvnd stores its files (registry and daemon logs). This property can only be defined as a system property into the command line Review Comment: I think that "on" is more idiomatic in this context :upside_down_face: (Not sure I've ever seen "into" used this way.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827674#comment-17827674
]
Herve Boutemy edited comment on MNG-8076 at 3/16/24 9:02 AM:
-
I know I can avoid and workaround, but the fact is that it should work from a
logical perspective: "don't do" is not really why I opened this issue with
precise info to have a chance to dig into it, because I feel there is a subtle
bug associated to it that people usually have hard time showing in a concrete
clearly defined shareable manner that gives us a chance
looking at MRESOLVER-333 PR, I'm surprised I don't have the "{{verifying that
is downloadable from}}" INFO message
https://github.com/apache/maven-resolver/pull/261/files#diff-24ffb8d00aab820a2ed733ffab91a18c6df52f2d2d1d94a5343894010eeef22bR385
it should be in my logs, isn't it?
was (Author: hboutemy):
I know I can avoid and workaround, but the fact is that it should work from a
logical perspective: "don't do" is not really why I opened this issue with
precise info to have a chance to dig into it, because I feel there is a subtle
bug associated to it
looking at MRESOLVER-333 PR, I'm surprised I don't have the "{{verifying that
is downloadable from}}" INFO message
https://github.com/apache/maven-resolver/pull/261/files#diff-24ffb8d00aab820a2ed733ffab91a18c6df52f2d2d1d94a5343894010eeef22bR385
it should be in my logs, isn't it?
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827674#comment-17827674
]
Herve Boutemy edited comment on MNG-8076 at 3/16/24 9:00 AM:
-
I know I can avoid and workaround, but the fact is that it should work from a
logical perspective: "don't do" is not really why I opened this issue with
precise info to have a chance to dig into it, because I feel there is a subtle
bug associated to it
looking at MRESOLVER-333 PR, I'm surprised I don't have the "{{verifying that
is downloadable from}}" INFO message
https://github.com/apache/maven-resolver/pull/261/files#diff-24ffb8d00aab820a2ed733ffab91a18c6df52f2d2d1d94a5343894010eeef22bR385
it should be in my logs, isn't it?
was (Author: hboutemy):
I know I can avoid and workaround, but the fact is that it should work from a
logical perspective: "don't do" is not really why I opened this issue with
precise info to have a chance to dig into it, because I feel there is a subtle
bug associated to it
looking at MRESOLVER-333 PR, I'm surprised I don't have the "verifying that is
downloadable from" INFO message
https://github.com/apache/maven-resolver/pull/261/files#diff-24ffb8d00aab820a2ed733ffab91a18c6df52f2d2d1d94a5343894010eeef22bR385
it should be in my logs, isn't it?
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827677#comment-17827677
]
Herve Boutemy commented on MNG-8076:
to give wider visibility in more logs:
{noformat}
[INFO] --< nl.basjes.parse.useragent:yauaa >---
[INFO] Building Yauaa : Analyzer 7.26.0 [3/24]
[INFO] from analyzer/pom.xml
[INFO] [ jar ]-
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
[WARNING] The POM for org.apache.maven.plugins:maven-shade-plugin:jar:3.5.2 is
missing, no dependency information available
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:jar:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:jar:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
[INFO]
[INFO] Reactor Summary for Yauaa : 7.26.0:
[INFO]
[INFO] Yauaa : SUCCESS [ 0.608 s]
[INFO] Yauaa : Code quality tools . SUCCESS [ 0.888 s]
[INFO] Yauaa : Analyzer ... FAILURE [ 0.025 s]
[INFO] Yauaa : UDF : .. SKIPPED
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.841 s
[INFO] Finished at: 2024-03-16T08:04:39Z
[INFO]
[ERROR] Plugin org.apache.maven.plugins:maven-shade-plugin:3.5.2 or one of its
dependencies could not be resolved: The following artifacts could not be
resolved: org.apache.maven.plugins:maven-shade-plugin:jar:3.5.2 (present, but
unavailable): org.apache.maven.plugins:maven-shade-plugin:jar:3.5.2 was not
found in https://repo.maven.apache.org/maven2 during a previous attempt. This
failure was cached in the local repository and resolution is not reattempted
until the update interval of central has elapsed or updates are forced -> [Help
1]
{noformat}
the INFO message is there 4 times (I don't complain, just counting, it's not a
problem)
I have one WARNING
but not the INFO about "verifying that is downloadable from" (was "Verifying
availability of " in previous Maven/Resolver versions)
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
>
[jira] [Commented] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827674#comment-17827674
]
Herve Boutemy commented on MNG-8076:
I know I can avoid and workaround, but the fact is that it should work from a
logical perspective: "don't do" is not really why I opened this issue with
precise info to have a chance to dig into it, because I feel there is a subtle
bug associated to it
looking at MRESOLVER-333 PR, I'm surprised I don't have the "verifying that is
downloadable from" INFO message
https://github.com/apache/maven-resolver/pull/261/files#diff-24ffb8d00aab820a2ed733ffab91a18c6df52f2d2d1d94a5343894010eeef22bR385
it should be there, isn't it?
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827674#comment-17827674
]
Herve Boutemy edited comment on MNG-8076 at 3/16/24 8:45 AM:
-
I know I can avoid and workaround, but the fact is that it should work from a
logical perspective: "don't do" is not really why I opened this issue with
precise info to have a chance to dig into it, because I feel there is a subtle
bug associated to it
looking at MRESOLVER-333 PR, I'm surprised I don't have the "verifying that is
downloadable from" INFO message
https://github.com/apache/maven-resolver/pull/261/files#diff-24ffb8d00aab820a2ed733ffab91a18c6df52f2d2d1d94a5343894010eeef22bR385
it should be in my logs, isn't it?
was (Author: hboutemy):
I know I can avoid and workaround, but the fact is that it should work from a
logical perspective: "don't do" is not really why I opened this issue with
precise info to have a chance to dig into it, because I feel there is a subtle
bug associated to it
looking at MRESOLVER-333 PR, I'm surprised I don't have the "verifying that is
downloadable from" INFO message
https://github.com/apache/maven-resolver/pull/261/files#diff-24ffb8d00aab820a2ed733ffab91a18c6df52f2d2d1d94a5343894010eeef22bR385
it should be there, isn't it?
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827672#comment-17827672
]
Tamas Cservenak commented on MNG-8076:
--
Never ever use staging repo mixed with central.
Whenever i check for reproducibility, always use -Dmaven.repo.local...
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1364) AbstractMavenReportRenderer should not depend on Doxia impl classes
[
https://issues.apache.org/jira/browse/MSHARED-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827671#comment-17827671
]
Michael Osipov commented on MSHARED-1364:
-
What do you recommend to do in such a case? Where should this class
({{SinkEventAttributeSet}}) be?
> AbstractMavenReportRenderer should not depend on Doxia impl classes
> ---
>
> Key: MSHARED-1364
> URL: https://issues.apache.org/jira/browse/MSHARED-1364
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M13
>Reporter: Konrad Windszus
>Priority: Major
>
> The classes in package {{o.a.m.doxia.sink.impl}} should by definition not be
> considered stable API (and therefore only consumed from Doxia classes
> internally).
> However
> {{https://github.com/apache/maven-reporting-impl/blob/72181306bb0e12eed50c4ba4aec98dd76499df39/src/main/java/org/apache/maven/reporting/AbstractMavenReportRenderer.java#L47}}
> depends on some internal constants.
> This is dangerous, as those constants were removed in the context of
> DOXIA-685. Although constants are inlined during compile time, the evaluation
> of those constants vanished as well, so using them has no longer any effect.
> Reporting Impl should only rely on stable Doxia API to achieve a better
> decoupling.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8076:
---
Summary: when jar in local repository from other repository id, should not
reject but check if it is also available in current repository id context
(was: when jar in local repository from other ids, should not reject but check
if it is also available in current context)
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-731) Simplify HTML emitted from Sink.verbatim(...)
[
https://issues.apache.org/jira/browse/DOXIA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827670#comment-17827670
]
ASF GitHub Bot commented on DOXIA-731:
--
michael-o commented on code in PR #202:
URL: https://github.com/apache/maven-doxia/pull/202#discussion_r1527133853
##
doxia-modules/doxia-module-markdown/src/test/java/org/apache/maven/doxia/module/markdown/MarkdownParserTest.java:
##
@@ -798,4 +800,24 @@ public void testQuoteVsApostrophe() throws Exception {
"This apostrophe isn't a quote." + "This \u2018quoted
text\u2019 isn't surrounded by apostrophes.",
content.toString());
}
+
+@Override
+protected void assertEventPrefix(Iterator eventIterator)
{
+assertSinkStartsWith(eventIterator, "head", "head_", "body");
+}
+
+@Override
+protected void assertEventSuffix(Iterator eventIterator)
{
+assertSinkEquals(eventIterator, "body_");
+}
+
+@Override
+protected String getVerbatimSource() {
+return null; // not supported in MD
Review Comment:
This isn't what a meant. I meant just add the link I have provided and
explain why we return null since this is not a missing/broken test.
> Simplify HTML emitted from Sink.verbatim(...)
> -
>
> Key: DOXIA-731
> URL: https://issues.apache.org/jira/browse/DOXIA-731
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The XHTML markup generated from Sink.verbatim(...) should be streamlined to
> either emit {{}} or {{}} depending on the given attribute.
> There is no need to generate an additional div nor any additional classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-731] Simplify HTML markup emitted from Sink.verbatim [maven-doxia]
michael-o commented on code in PR #202:
URL: https://github.com/apache/maven-doxia/pull/202#discussion_r1527133853
##
doxia-modules/doxia-module-markdown/src/test/java/org/apache/maven/doxia/module/markdown/MarkdownParserTest.java:
##
@@ -798,4 +800,24 @@ public void testQuoteVsApostrophe() throws Exception {
"This apostrophe isn't a quote." + "This \u2018quoted
text\u2019 isn't surrounded by apostrophes.",
content.toString());
}
+
+@Override
+protected void assertEventPrefix(Iterator eventIterator)
{
+assertSinkStartsWith(eventIterator, "head", "head_", "body");
+}
+
+@Override
+protected void assertEventSuffix(Iterator eventIterator)
{
+assertSinkEquals(eventIterator, "body_");
+}
+
+@Override
+protected String getVerbatimSource() {
+return null; // not supported in MD
Review Comment:
This isn't what a meant. I meant just add the link I have provided and
explain why we return null since this is not a missing/broken test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MNG-8076) when jar in local repository from other ids, should not reject but check if it is also available in current context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8076:
---
Description:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
downloaded the reference jar in a staging remote repository with "reference" id
(that's part of the artifact:compare logic in Apache staging: see
https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for details
on this recent Reproducible Central feature)
When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id does not mean that they are not *also* available with the
"central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
for now, I know that by rebuilding releases from Apache staging area, I'm
polluting my local repository :/
was:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
downloaded the reference jar in a staging remote repository with "reference" id
(that's part of the artifact:compare logic in Apache staging: see
https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for details
on this recent Reproducible Central feature)
When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
> when jar in local repository from other ids, should not reject but check if
> it is also available in current context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO]
[jira] [Commented] (MPLUGIN-501) Upgrade to Doxia 2.0.0 Milestone Stack
[ https://issues.apache.org/jira/browse/MPLUGIN-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827669#comment-17827669 ] Michael Osipov commented on MPLUGIN-501: Already done some time ago: https://github.com/apache/maven-fluido-skin/blob/d5eef2752bdb2e3d395438a502ab87ecbebd9e8c/src/main/resources/META-INF/maven/skin.xml#L25 > Upgrade to Doxia 2.0.0 Milestone Stack > -- > > Key: MPLUGIN-501 > URL: https://issues.apache.org/jira/browse/MPLUGIN-501 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > * Upgrade to Doxia 2.0.0-M8 > * Upgrade to Doxia Sitetools 2.0.0-M16 > * Upgrade to Commons Lang 3.14.0 > * Upgrade to Maven Site Plugin 4.0.0-M13 > * Upgrade to Maven Project Info Reports Plugin 4.0.0-M1 > * Upgrade to Plexus Velocity 2.1.0 > * Upgrade to Maven Reporting API 4.0.0-M9 > * Upgrade to Maven Reporting Impl 4.0.0-M13 > * Upgrade to Velocity Engine 2.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8076) when jar in local repository from other ids, should not reject but check if it is also available in current context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8076:
---
Description:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
downloaded the reference jar in a staging remote repository with "reference" id
(that's part of the artifact:compare logic in Apache staging: see
https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for details
on this recent Reproducible Central feature)
When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
was:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
downloaded the reference jar in a staging remote repository with "reference" id
(that's part of the artifact:compare logic in Apache staging)
When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
> when jar in local repository from other ids, should not reject but check if
> it is also available in current context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central
[jira] [Updated] (MNG-8076) when jar in local repository from other ids, should not reject but check if it is also available in current context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8076:
---
Description:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
downloaded the reference jar in a staging remote repository with "reference" id
(that's part of the artifact:compare logic in Apache staging)
When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
was:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
in the past, I rebuilt maven-shade-plugin 3.5.2, which downloaded the reference
jar in a remote repository with "reference" id (that's part of the
artifact:compare logic)
When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
> when jar in local repository from other ids, should not reject but check if
> it is also available in current context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed
[jira] [Updated] (MNG-8076) when jar in local repository from other ids, should not reject but check if it is also available in current context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8076:
---
Description:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
in the past, I rebuilt maven-shade-plugin 3.5.2, which downloaded the reference
jar in a remote repository with "reference" id (that's part of the
artifact:compare logic)
When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
was:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
I rebuild maven-shade-plugin 3.5.2, which downloaded its jar in a repository
with "reference" id
When I'm trying to rebuild a project that uses this release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
> when jar in local repository from other ids, should not reject but check if
> it is also available in current context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2, which downloaded the
> reference jar in a remote repository with "reference" id (that's part of the
> artifact:compare logic)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
>
[jira] [Commented] (DOXIA-734) XHTML 1 elements/attributes which are obsolete in XHTML5 no longer detected by XdocParser/FmlParser
[
https://issues.apache.org/jira/browse/DOXIA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827668#comment-17827668
]
Michael Osipov commented on DOXIA-734:
--
I don't see a reason to drop FML although I thought about it i the first place
because it is just and it does work. As said, it also proves that our
programmic logic works.
[~hboutemy], please take the time and read. The time will be given. No need to
rush.
> XHTML 1 elements/attributes which are obsolete in XHTML5 no longer detected
> by XdocParser/FmlParser
> ---
>
> Key: DOXIA-734
> URL: https://issues.apache.org/jira/browse/DOXIA-734
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Apt, Module - Fml
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently only {{}} is translated into a proper
> {{Sink.anchor(...)}} call.
> The obsolete {{}} is currently not calling an according
> {{Sink.anchor(...)}} method but may be still used in ancient markups which
> derive from the XHtml5BaseParser.
> For example XDoc and FML both stem from the time where
> https://www.w3.org/TR/xhtml1/ was the most recent XHTML spec and therefore
> support {{a name}} (according to
> https://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-xdoc/xsddoc/http___maven.apache.org_XDOC_2.0/element/a.html
> and
> https://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-fml/xsddoc/http___maven.apache.org_FML_1.0.1/element/a.html)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8076) when jar in local repository from other ids, should not reject but check if it is also available in current context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8076:
---
Description:
precise context: Reproducible Central
https://github.com/jvm-repo-rebuild/reproducible-central
I rebuild maven-shade-plugin 3.5.2, which downloaded its jar in a repository
with "reference" id
When I'm trying to rebuild a project that uses this release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
was:
precise context: Reproducible Central
I rebuild maven-shade-plugin 3.5.2, which downloaded its jar in a repository
with "reference" id
When I'm trying to rebuild a project that uses this release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
> when jar in local repository from other ids, should not reject but check if
> it is also available in current context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> I rebuild maven-shade-plugin 3.5.2, which downloaded its jar in a repository
> with "reference" id
> When I'm trying to rebuild a project that uses this release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference"
[jira] [Created] (MNG-8076) when jar in local repository from other ids, should not reject but check if it is also available in current context
Herve Boutemy created MNG-8076:
--
Summary: when jar in local repository from other ids, should not
reject but check if it is also available in current context
Key: MNG-8076
URL: https://issues.apache.org/jira/browse/MNG-8076
Project: Maven
Issue Type: Bug
Affects Versions: 3.9.6
Reporter: Herve Boutemy
precise context: Reproducible Central
I rebuild maven-shade-plugin 3.5.2, which downloaded its jar in a repository
with "reference" id
When I'm trying to rebuild a project that uses this release, I get:
{noformat}
[INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
present in the local repository, but cached from a remote repository ID that is
unavailable in current build context, verifying that is downloadable from
[central (https://repo.maven.apache.org/maven2, default, releases)]
{noformat}
looking in the local repository, I get
{noformat}
cat
~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be
changed without prior notice.
#Sun Feb 18 15:03:27 UTC 2024
maven-shade-plugin-3.5.2-sources.jar>reference=
maven-shade-plugin-3.5.2.pom>reference=
maven-shade-plugin-3.5.2.jar>reference=
maven-shade-plugin-3.5.2-source-release.zip>reference=
maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
maven-shade-plugin-3.5.2-cyclonedx.json>reference=
{noformat}
the fact that all these artifacts were initially downloaded through "reference"
repository id do not mean that they are not also available with the "central" id
as a precise workaround, i did not delete the _remote.repositories file but
replaced reference with central and it works as expected. The opposite update
can restore the failing behaviour...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
