[jira] [Closed] (MSOURCES-140) Build fails when using install deploy
[ https://issues.apache.org/jira/browse/MSOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSOURCES-140. -- Assignee: Herve Boutemy Resolution: Fixed > Build fails when using install deploy > - > > Key: MSOURCES-140 > URL: https://issues.apache.org/jira/browse/MSOURCES-140 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Joern >Assignee: Herve Boutemy >Priority: Minor > Fix For: next-release > > > By configuration maven-source-plugin is bound to verify phase. > When executing commands like mvn install deploy, which includes phase verify > 2 times, the build fails with error "We have duplicated artifacts attached." > - it worked with 3.2.1 > When just using mvn deploy it works. > I know install and deploy together are redundant but in many build pipelines > it is used that way and maven as such also allows the combination. > Probably caused by MSOURCES-121 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHADE-471) still timestamp issues with timezones (DST)
[
https://issues.apache.org/jira/browse/MSHADE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHADE-471:
-
Summary: still timestamp issues with timezones (DST) (was: still timestamp
issues with timezones (DST?))
> still timestamp issues with timezones (DST)
> ---
>
> Key: MSHADE-471
> URL: https://issues.apache.org/jira/browse/MSHADE-471
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.5.3
>
>
> MSHADE-420 is incomplete, problems still appear like
> {noformat}1 / 1
> target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> toolbox/target/toolbox-0.1.5-cli.jar
> --- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> +++ toolbox/target/toolbox-0.1.5-cli.jar
> ├── zipinfo {}
> │ @@ -735,96 +735,96 @@
> │ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
> META-INF/maven/org.jline/jline/pom.properties
> │ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/
> │ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/
> │ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
> eu/maveniverse/maven/toolbox/shared/
> {noformat}
> https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
> (fixed since then by using a TZ, but initial UTC shows the issue)
> looks related to DST: probably need to apply what has been done in
> plexus-archiver
> https://github.com/codehaus-plexus/plexus-archiver/commit/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MARTIFACT-64) add diagnose and hints for Git commit timestamp support
[ https://issues.apache.org/jira/browse/MARTIFACT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MARTIFACT-64. -- Assignee: Herve Boutemy Resolution: Fixed > add diagnose and hints for Git commit timestamp support > --- > > Key: MARTIFACT-64 > URL: https://issues.apache.org/jira/browse/MARTIFACT-64 > Project: Maven Artifact Plugin > Issue Type: Improvement >Affects Versions: 3.5.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Labels: pull-request-available > Fix For: 3.5.2 > > > some issues with Git commit timestamp support has been reported: need to > investigate root cause and provide help -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARCHETYPE-626) mvn install deploy does not work with 3.2.1 but worked with 3.2.0
[
https://issues.apache.org/jira/browse/ARCHETYPE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed ARCHETYPE-626.
---
Assignee: Herve Boutemy
Resolution: Fixed
> mvn install deploy does not work with 3.2.1 but worked with 3.2.0
> -
>
> Key: ARCHETYPE-626
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-626
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.2.1
> Environment: * Linux machine (Kernel 3.10.0)
> * OpenJDK 11.0.13.0.8-1.el7_9.x86_64 (11.0.1)
> * Maven 3.8.4 (did also occur with 3.3.9)
>Reporter: Jan Mosig
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.3.0
>
> Attachments: archetype-plugin-failed-build.txt,
> archetype-plugin-successful-build.txt
>
>
> Hi there,
> I've got an archetype build that used to work fine with 3.2.0 but fails with
> 3.2.1.
> The problem with 3.2.1 is that all the files in
> target/test-classes/projects/it-basic/project/basic-project do exist but are
> all empty (0 bytes).
> The build is run with {{mvn -U clean install deploy}}. If I run it with {{mvn
> -U clean deploy}} it works. Although the install goal may be superfluous, I
> guess there is something wrong there with version 3.2.1.
> I attached the logs of a successful run and a failed one to this ticket.
> You may find the failing project here (Branch archetype-plugin-321-bug):
> https://github.com/itemis/fluffyj-archetype/tree/archetype-plugin-321-bug
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARCHETYPE-657) create target/archetype-it instead of target/classes/archetype-it
[
https://issues.apache.org/jira/browse/ARCHETYPE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed ARCHETYPE-657.
---
Assignee: Herve Boutemy
Resolution: Fixed
> create target/archetype-it instead of target/classes/archetype-it
> -
>
> Key: ARCHETYPE-657
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-657
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.2, 3.2.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.3.0
>
>
> in ARCHETYPE-389, {{archetype-it}} directory has been created to store
> interpolated settings file, which is local to current build
> this directory has been created in {{target/classes/}}: should have been in
> {{target/}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MARTIFACT-64) add diagnose and hints for Git commit timestamp support
Herve Boutemy created MARTIFACT-64: -- Summary: add diagnose and hints for Git commit timestamp support Key: MARTIFACT-64 URL: https://issues.apache.org/jira/browse/MARTIFACT-64 Project: Maven Artifact Plugin Issue Type: Improvement Affects Versions: 3.5.1 Reporter: Herve Boutemy Fix For: 3.5.2 some issues with Git commit timestamp support has been reported: need to investigate root cause and provide help -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MARTIFACT-63) rework plugin-issues.apt generation
[ https://issues.apache.org/jira/browse/MARTIFACT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MARTIFACT-63. -- Assignee: Herve Boutemy Resolution: Fixed > rework plugin-issues.apt generation > --- > > Key: MARTIFACT-63 > URL: https://issues.apache.org/jira/browse/MARTIFACT-63 > Project: Maven Artifact Plugin > Issue Type: Improvement >Affects Versions: 3.5.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Labels: pull-request-available > Fix For: 3.5.2 > > > having the content saved to src/site/apt in Git creates confusion: better to > generate content to target/generated-site/apt > and comments column is now causing trouble because there is too much content > that should not be displayed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MARTIFACT-63) rework plugin-issues.apt generation
Herve Boutemy created MARTIFACT-63: -- Summary: rework plugin-issues.apt generation Key: MARTIFACT-63 URL: https://issues.apache.org/jira/browse/MARTIFACT-63 Project: Maven Artifact Plugin Issue Type: Improvement Affects Versions: 3.5.1 Reporter: Herve Boutemy Fix For: 3.5.2 having the content saved to src/site/apt in Git creates confusion: better to generate content to target/generated-site/apt and comments column is now causing trouble because there is too much content that should not be displayed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MARTIFACT-62) Drop deprecated things, replace them with current ones
[ https://issues.apache.org/jira/browse/MARTIFACT-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MARTIFACT-62. -- Assignee: Tamas Cservenak Resolution: Fixed > Drop deprecated things, replace them with current ones > -- > > Key: MARTIFACT-62 > URL: https://issues.apache.org/jira/browse/MARTIFACT-62 > Project: Maven Artifact Plugin > Issue Type: Task >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Labels: pull-request-available > Fix For: 3.5.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHADE-472) upgrade parent POM
[ https://issues.apache.org/jira/browse/MSHADE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHADE-472. Assignee: Herve Boutemy Resolution: Fixed > upgrade parent POM > -- > > Key: MSHADE-472 > URL: https://issues.apache.org/jira/browse/MSHADE-472 > Project: Maven Shade Plugin > Issue Type: Task >Affects Versions: 3.5.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.5.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHADE-472) upgrade parent POM
Herve Boutemy created MSHADE-472: Summary: upgrade parent POM Key: MSHADE-472 URL: https://issues.apache.org/jira/browse/MSHADE-472 Project: Maven Shade Plugin Issue Type: Task Affects Versions: 3.5.2 Reporter: Herve Boutemy Fix For: 3.5.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHADE-471) still timestamp issues with timezones (DST?)
[
https://issues.apache.org/jira/browse/MSHADE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHADE-471:
-
Summary: still timestamp issues with timezones (DST?) (was: still
timestamp issues)
> still timestamp issues with timezones (DST?)
>
>
> Key: MSHADE-471
> URL: https://issues.apache.org/jira/browse/MSHADE-471
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.5.3
>
>
> MSHADE-420 is incomplete, problems still appear like
> {noformat}1 / 1
> target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> toolbox/target/toolbox-0.1.5-cli.jar
> --- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> +++ toolbox/target/toolbox-0.1.5-cli.jar
> ├── zipinfo {}
> │ @@ -735,96 +735,96 @@
> │ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
> META-INF/maven/org.jline/jline/pom.properties
> │ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/
> │ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/
> │ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
> eu/maveniverse/maven/toolbox/shared/
> {noformat}
> https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
> (fixed since then by using a TZ, but initial UTC shows the issue)
> looks related to DST: probably need to apply what has been done in
> plexus-archiver
> https://github.com/codehaus-plexus/plexus-archiver/commit/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838375#comment-17838375
]
Herve Boutemy commented on MNG-8097:
perhaps just adding an INFO message "using default extension = type,
addedToClasspath=false, includesDependency=false for dependency xxx"?
not really a warning, just a fact
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}}, {{includesDependencies}} and
> {{classifier}} from the artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-307) Commons-io class not found
[
https://issues.apache.org/jira/browse/MJAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837537#comment-17837537
]
Herve Boutemy commented on MJAR-307:
IIUC, the plugin does not fail with
{noformat}2024-03-06T19:57:04Z{noformat}
but it fails with
{noformat}20240306{noformat}
= when user defines EPOCH style value (no real need for
maven.build.timestamp.format nor ${maven.build.timestamp})
I just tested on a project and I confirm: EPOCH style values make the plugin
fail
> Commons-io class not found
> --
>
> Key: MJAR-307
> URL: https://issues.apache.org/jira/browse/MJAR-307
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Delany
>Assignee: Slawomir Jaranowski
>Priority: Critical
>
> With Maven 3.9.6 and upgrading from plugin version 3.3.0 I now get this error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar (default-jar) on project
> comet:
> Execution default-jar of goal
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar
> failed: A required class was missing while executing
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar:
> org/apache/commons/io/file/attribute/FileTimes
> [ERROR] -
>
> [ERROR] realm = plugin>org.apache.maven.plugins:maven-jar-plugin:3.4.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
>
>
>
> [ERROR] urls[0] =
> [file:/home/sol/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/3.4.0/maven-jar-plugin-3.4.0.jar|file:///home/sol/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/3.4.0/maven-jar-plugin-3.4.0.jar]
> [ERROR] urls[1] =
> [file:/home/sol/.m2/repository/org/apache/maven/shared/file-management/3.1.0/file-management-3.1.0.jar|file:///home/sol/.m2/repository/org/apache/maven/shared/file-management/3.1.0/file-management-3.1.0.jar]
> [ERROR] urls[2] =
> [file:/home/sol/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar|file:///home/sol/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar]
> [ERROR] urls[3] =
> [file:/home/sol/.m2/repository/org/apache/maven/maven-archiver/3.6.2/maven-archiver-3.6.2.jar|file:///home/sol/.m2/repository/org/apache/maven/maven-archiver/3.6.2/maven-archiver-3.6.2.jar]
> [ERROR] urls[4] =
> [file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.27/plexus-interpolation-1.27.jar|file:///home/sol/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.27/plexus-interpolation-1.27.jar]
> [ERROR] urls[5] =
> [file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-utils/4.0.0/plexus-utils-4.0.0.jar|file:///home/sol/.m2/repository/org/codehaus/plexus/plexus-utils/4.0.0/plexus-utils-4.0.0.jar]
> [ERROR] urls[6] =
> [file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-archiver/4.9.2/plexus-archiver-4.9.2.jar|file:///home/sol/.m2/repository/org/codehaus/plexus/plexus-archiver/4.9.2/plexus-archiver-4.9.2.jar]
> [ERROR] urls[7] =
> [file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-io/3.4.2/plexus-io-3.4.2.jar|file:///home/sol/.m2/repository/org/codehaus/plexus/plexus-io/3.4.2/plexus-io-3.4.2.jar]
> [ERROR] urls[8] =
> [file:/home/sol/.m2/repository/org/apache/commons/commons-compress/1.26.1/commons-compress-1.26.1.jar|file:///home/sol/.m2/repository/org/apache/commons/commons-compress/1.26.1/commons-compress-1.26.1.jar]
> [ERROR] urls[9] =
> [file:/home/sol/.m2/repository/org/apache/commons/commons-lang3/3.14.0/commons-lang3-3.14.0.jar|file:///home/sol/.m2/repository/org/apache/commons/commons-lang3/3.14.0/commons-lang3-3.14.0.jar]
> [ERROR] urls[10] =
> [file:/home/sol/.m2/repository/commons-codec/commons-codec/1.16.1/commons-codec-1.16.1.jar|file:///home/sol/.m2/repository/commons-codec/commons-codec/1.16.1/commons-codec-1.16.1.jar]
> [ERROR] urls[11] =
> [file:/home/sol/.m2/repository/org/iq80/snappy/snappy/0.4/snappy-0.4.jar|file:///home/sol/.m2/repository/org/iq80/snappy/snappy/0.4/snappy-0.4.jar]
> [ERROR] urls[12] =
> [file:/home/sol/.m2/repository/org/tukaani/xz/1.9/xz-1.9.jar|file:///home/sol/.m2/repository/org/tukaani/xz/1.9/xz-1.9.jar]
> [ERROR] urls[13] =
> [file:/home/sol/.m2/repository/com/github/luben/zstd-jni/1.5.5-11/zstd-jni-1.5.5-11.jar|file:///home/sol/.m2/repository/com/github/luben/zstd-jni/1.5.5-11/zstd-jni-1.5.5-11.jar]
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]]
> {noformat}
> not sure if I'm only seeing it because of this configuration
> {code:xml}
>
>
[jira] [Commented] (MJAR-307) Commons-io class not found
[
https://issues.apache.org/jira/browse/MJAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837448#comment-17837448
]
Herve Boutemy commented on MJAR-307:
does it mean that ASF parent vote should be cancelled?
> Commons-io class not found
> --
>
> Key: MJAR-307
> URL: https://issues.apache.org/jira/browse/MJAR-307
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Delany
>Assignee: Slawomir Jaranowski
>Priority: Critical
>
> With Maven 3.9.6 and upgrading from plugin version 3.3.0 I now get this error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar (default-jar) on project
> comet:
> Execution default-jar of goal
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar
> failed: A required class was missing while executing
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar:
> org/apache/commons/io/file/attribute/FileTimes
> [ERROR] -
>
> [ERROR] realm = plugin>org.apache.maven.plugins:maven-jar-plugin:3.4.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
>
>
>
> [ERROR] urls[0] =
> [file:/home/sol/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/3.4.0/maven-jar-plugin-3.4.0.jar|file:///home/sol/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/3.4.0/maven-jar-plugin-3.4.0.jar]
> [ERROR] urls[1] =
> [file:/home/sol/.m2/repository/org/apache/maven/shared/file-management/3.1.0/file-management-3.1.0.jar|file:///home/sol/.m2/repository/org/apache/maven/shared/file-management/3.1.0/file-management-3.1.0.jar]
> [ERROR] urls[2] =
> [file:/home/sol/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar|file:///home/sol/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar]
> [ERROR] urls[3] =
> [file:/home/sol/.m2/repository/org/apache/maven/maven-archiver/3.6.2/maven-archiver-3.6.2.jar|file:///home/sol/.m2/repository/org/apache/maven/maven-archiver/3.6.2/maven-archiver-3.6.2.jar]
> [ERROR] urls[4] =
> [file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.27/plexus-interpolation-1.27.jar|file:///home/sol/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.27/plexus-interpolation-1.27.jar]
> [ERROR] urls[5] =
> [file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-utils/4.0.0/plexus-utils-4.0.0.jar|file:///home/sol/.m2/repository/org/codehaus/plexus/plexus-utils/4.0.0/plexus-utils-4.0.0.jar]
> [ERROR] urls[6] =
> [file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-archiver/4.9.2/plexus-archiver-4.9.2.jar|file:///home/sol/.m2/repository/org/codehaus/plexus/plexus-archiver/4.9.2/plexus-archiver-4.9.2.jar]
> [ERROR] urls[7] =
> [file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-io/3.4.2/plexus-io-3.4.2.jar|file:///home/sol/.m2/repository/org/codehaus/plexus/plexus-io/3.4.2/plexus-io-3.4.2.jar]
> [ERROR] urls[8] =
> [file:/home/sol/.m2/repository/org/apache/commons/commons-compress/1.26.1/commons-compress-1.26.1.jar|file:///home/sol/.m2/repository/org/apache/commons/commons-compress/1.26.1/commons-compress-1.26.1.jar]
> [ERROR] urls[9] =
> [file:/home/sol/.m2/repository/org/apache/commons/commons-lang3/3.14.0/commons-lang3-3.14.0.jar|file:///home/sol/.m2/repository/org/apache/commons/commons-lang3/3.14.0/commons-lang3-3.14.0.jar]
> [ERROR] urls[10] =
> [file:/home/sol/.m2/repository/commons-codec/commons-codec/1.16.1/commons-codec-1.16.1.jar|file:///home/sol/.m2/repository/commons-codec/commons-codec/1.16.1/commons-codec-1.16.1.jar]
> [ERROR] urls[11] =
> [file:/home/sol/.m2/repository/org/iq80/snappy/snappy/0.4/snappy-0.4.jar|file:///home/sol/.m2/repository/org/iq80/snappy/snappy/0.4/snappy-0.4.jar]
> [ERROR] urls[12] =
> [file:/home/sol/.m2/repository/org/tukaani/xz/1.9/xz-1.9.jar|file:///home/sol/.m2/repository/org/tukaani/xz/1.9/xz-1.9.jar]
> [ERROR] urls[13] =
> [file:/home/sol/.m2/repository/com/github/luben/zstd-jni/1.5.5-11/zstd-jni-1.5.5-11.jar|file:///home/sol/.m2/repository/com/github/luben/zstd-jni/1.5.5-11/zstd-jni-1.5.5-11.jar]
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]]
> {noformat}
> not sure if I'm only seeing it because of this configuration
> {code:xml}
>
>
> true
>
>
> true
>
>
> ${build.number}
> ${build.sealed}
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837433#comment-17837433
]
Herve Boutemy commented on MNG-8097:
by "validate", you mean "fail with a message on unknown dependency types" and
"force user to declare an extension that defines dependency type via an
artifact handler"?
this will be more complex to users, who for example are used to using "zip"
(non-existent) dependency type in a lazy way
perhaps something for Maven 4?
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}} and {{includesDependencies}} from the
> artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHADE-471) still timestamp issues
[
https://issues.apache.org/jira/browse/MSHADE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHADE-471:
-
Description:
MSHADE-420 is incomplete, problems still appear like
{noformat}1 / 1
target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
toolbox/target/toolbox-0.1.5-cli.jar
--- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
+++ toolbox/target/toolbox-0.1.5-cli.jar
├── zipinfo {}
│ @@ -735,96 +735,96 @@
│ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
META-INF/maven/org.jline/jline/pom.properties
│ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/
│ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/jni-config.json
...
│ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/
│ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/jni-config.json
...
│ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
eu/maveniverse/maven/toolbox/shared/
{noformat}
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
(fixed since then by using a TZ, but initial UTC shows the issue)
looks related to DST: probably need to apply what has been done in
plexus-archiver
https://github.com/codehaus-plexus/plexus-archiver/commit/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36
was:
MSHADE-420 is incomplete, problems still appear like
{noformat}1 / 1
target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
toolbox/target/toolbox-0.1.5-cli.jar
--- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
+++ toolbox/target/toolbox-0.1.5-cli.jar
├── zipinfo {}
│ @@ -735,96 +735,96 @@
│ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
META-INF/maven/org.jline/jline/pom.properties
│ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/
│ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/jni-config.json
...
│ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/
│ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/jni-config.json
...
│ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
eu/maveniverse/maven/toolbox/shared/
{noformat}
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
looks related to DST: probably need to apply what has been done in
plexus-archiver
https://github.com/codehaus-plexus/plexus-archiver/commit/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36
> still timestamp issues
> --
>
> Key: MSHADE-471
> URL: https://issues.apache.org/jira/browse/MSHADE-471
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.5.3
>
>
> MSHADE-420 is incomplete, problems still appear like
> {noformat}1 / 1
> target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> toolbox/target/toolbox-0.1.5-cli.jar
> --- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> +++ toolbox/target/toolbox-0.1.5-cli.jar
> ├── zipinfo {}
> │ @@ -735,96 +735,96 @@
> │ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
> META-INF/maven/org.jline/jline/pom.properties
> │ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/
> │ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/
> │ +-rw
[jira] [Closed] (MSHADE-471) still timestamp issues
[
https://issues.apache.org/jira/browse/MSHADE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSHADE-471.
Assignee: Herve Boutemy
Resolution: Fixed
> still timestamp issues
> --
>
> Key: MSHADE-471
> URL: https://issues.apache.org/jira/browse/MSHADE-471
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: next-release
>
>
> MSHADE-420 is incomplete, problems still appear like
> {noformat}1 / 1
> target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> toolbox/target/toolbox-0.1.5-cli.jar
> --- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> +++ toolbox/target/toolbox-0.1.5-cli.jar
> ├── zipinfo {}
> │ @@ -735,96 +735,96 @@
> │ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
> META-INF/maven/org.jline/jline/pom.properties
> │ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/
> │ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/
> │ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
> eu/maveniverse/maven/toolbox/shared/
> {noformat}
> https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
> looks related to DST: probably need to apply what has been done in
> plexus-archiver
> https://github.com/codehaus-plexus/plexus-archiver/commit/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MARTIFACT-60) artifact:3.5.0:check-buildplan is too chatty by default
[
https://issues.apache.org/jira/browse/MARTIFACT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MARTIFACT-60.
--
Fix Version/s: 3.5.2
Assignee: Herve Boutemy
Resolution: Fixed
> artifact:3.5.0:check-buildplan is too chatty by default
> ---
>
> Key: MARTIFACT-60
> URL: https://issues.apache.org/jira/browse/MARTIFACT-60
> Project: Maven Artifact Plugin
> Issue Type: Improvement
> Components: artifact:check-buildplan
>Affects Versions: 3.5.0, 3.5.1
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\java\apache-maven-3.9.6
> Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program
> Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Assignee: Herve Boutemy
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.5.2
>
>
> Running the plugin is too chatty by default, for example, I don't need
> everything that's NOT wrong. Just tell me what's wrong or nothing:
> {noformat}
> [INFO] — artifact:3.5.0:check-buildplan (check-buildplan) @ commons-io —
> [INFO] no known issue with
> org.apache.maven.plugins:maven-enforcer-plugin:3.4.1
> [INFO] no known issue with org.apache.rat:apache-rat-plugin:0.16.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-artifact-plugin:3.5.0
> [INFO] no known issue with org.codehaus.mojo:build-helper-maven-plugin:3.5.0
> [INFO] no known issue with org.apache.maven.plugins:maven-antrun-plugin:3.1.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0 (>= 1.7.0)
> [INFO] no known issue with org.codehaus.mojo:buildnumber-maven-plugin:3.2.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-resources-plugin:3.3.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-compiler-plugin:3.13.0
> [INFO] no known issue with org.apache.felix:maven-bundle-plugin:5.1.9 (>=
> 5.1.9)
> [INFO] no known issue with org.jacoco:jacoco-maven-plugin:0.8.11
> [INFO] no known issue with
> org.apache.maven.plugins:maven-surefire-plugin:3.2.5
> [INFO] no known issue with org.apache.maven.plugins:maven-jar-plugin:3.3.0
> (>= 3.2.0)
> [INFO] no known issue with org.apache.maven.plugins:maven-site-plugin:3.12.1
> [INFO] no known issue with org.apache.maven.plugins:maven-source-plugin:3.2.1
> (>= 3.2.1)
> [INFO] no known issue with org.cyclonedx:cyclonedx-maven-plugin:2.8.0
> [INFO] no known issue with org.spdx:spdx-maven-plugin:0.7.3
> [INFO] no known issue with org.moditect:moditect-maven-plugin:1.2.1.Final (>=
> 1.0.0.Final)
> [INFO] no known issue with org.apache.maven.plugins:maven-install-plugin:3.1.1
> [INFO] no known issue with org.apache.maven.plugins:maven-deploy-plugin:3.1.1
> {noformat}
> Either say nothing or, if you must, perhaps a single log event:
> "No issues found in 16 plugins." Note that sentences should start with a
> capital letter.
> The current info would be fine at the debug logging level IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHADE-471) still timestamp issues
[
https://issues.apache.org/jira/browse/MSHADE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHADE-471:
-
Fix Version/s: next-release
> still timestamp issues
> --
>
> Key: MSHADE-471
> URL: https://issues.apache.org/jira/browse/MSHADE-471
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: next-release
>
>
> MSHADE-420 is incomplete, problems still appear like
> {noformat}1 / 1
> target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> toolbox/target/toolbox-0.1.5-cli.jar
> --- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> +++ toolbox/target/toolbox-0.1.5-cli.jar
> ├── zipinfo {}
> │ @@ -735,96 +735,96 @@
> │ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
> META-INF/maven/org.jline/jline/pom.properties
> │ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/
> │ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/
> │ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
> eu/maveniverse/maven/toolbox/shared/
> {noformat}
> https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
> looks related to DST: probably need to apply what has been done in
> plexus-archiver
> https://github.com/codehaus-plexus/plexus-archiver/commit/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHADE-471) still timestamp issues
[
https://issues.apache.org/jira/browse/MSHADE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHADE-471:
-
Description:
MSHADE-420 is incomplete, problems still appear like
{noformat}1 / 1
target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
toolbox/target/toolbox-0.1.5-cli.jar
--- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
+++ toolbox/target/toolbox-0.1.5-cli.jar
├── zipinfo {}
│ @@ -735,96 +735,96 @@
│ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
META-INF/maven/org.jline/jline/pom.properties
│ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/
│ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/jni-config.json
...
│ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/
│ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/jni-config.json
...
│ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
eu/maveniverse/maven/toolbox/shared/
{noformat}
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
looks related to DST: probably need to apply what has been done in
plexus-archiver
https://github.com/codehaus-plexus/plexus-archiver/commit/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36
was:
MSHADE-420 is incomplete, problems still appear like
{noformat}1 / 1
target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
toolbox/target/toolbox-0.1.5-cli.jar
--- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
+++ toolbox/target/toolbox-0.1.5-cli.jar
├── zipinfo {}
│ @@ -735,96 +735,96 @@
│ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
META-INF/maven/org.jline/jline/pom.properties
│ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/
│ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/jni-config.json
...
│ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/
│ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/jni-config.json
...
│ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
eu/maveniverse/maven/toolbox/shared/
{noformat}
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
> still timestamp issues
> --
>
> Key: MSHADE-471
> URL: https://issues.apache.org/jira/browse/MSHADE-471
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Herve Boutemy
>Priority: Major
>
> MSHADE-420 is incomplete, problems still appear like
> {noformat}1 / 1
> target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> toolbox/target/toolbox-0.1.5-cli.jar
> --- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
> +++ toolbox/target/toolbox-0.1.5-cli.jar
> ├── zipinfo {}
> │ @@ -735,96 +735,96 @@
> │ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
> META-INF/maven/org.jline/jline/pom.properties
> │ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/
> │ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.properties
> │ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/
> │ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
> META-INF/native-image/jansi/jni-config.json
> ...
> │ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
> META-INF/maven/org.fusesource.jansi/jansi/pom.xml
> │ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
>
[jira] [Created] (MSHADE-471) still timestamp issues
Herve Boutemy created MSHADE-471:
Summary: still timestamp issues
Key: MSHADE-471
URL: https://issues.apache.org/jira/browse/MSHADE-471
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 3.5.2
Reporter: Herve Boutemy
MSHADE-420 is incomplete, problems still appear like
{noformat}1 / 1
target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
toolbox/target/toolbox-0.1.5-cli.jar
--- target/reference/eu.maveniverse.maven.plugins/toolbox-0.1.5-cli.jar
+++ toolbox/target/toolbox-0.1.5-cli.jar
├── zipinfo {}
│ @@ -735,96 +735,96 @@
│ -rw 2.0 fat 50 bl defN 24-Jan-23 12:20
META-INF/maven/org.jline/jline/pom.properties
│ --rw 2.0 fat0 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/
│ --rw 2.0 fat12491 bl defN 23-Oct-12 07:38
META-INF/native-image/jansi/jni-config.json
...
│ --rw 2.0 fat17329 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ --rw 2.0 fat 60 bl defN 23-Oct-12 07:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ +-rw 2.0 fat0 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/
│ +-rw 2.0 fat12491 bl defN 23-Oct-12 06:38
META-INF/native-image/jansi/jni-config.json
...
│ +-rw 2.0 fat17329 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.xml
│ +-rw 2.0 fat 60 bl defN 23-Oct-12 06:38
META-INF/maven/org.fusesource.jansi/jansi/pom.properties
│ -rw 2.0 fat0 bl defN 24-Apr-11 20:18
eu/maveniverse/maven/toolbox/shared/
{noformat}
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/eu/maveniverse/maven/toolbox/README.md
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPOM-478) Remove manually maintained history from site
[ https://issues.apache.org/jira/browse/MPOM-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835160#comment-17835160 ] Herve Boutemy commented on MPOM-478: good idea: these links were useful with svn because ViewVC did not help much: but with GitHub UX, they are not necessary any more let's benefit from it to simplify the release process > Remove manually maintained history from site > > > Key: MPOM-478 > URL: https://issues.apache.org/jira/browse/MPOM-478 > Project: Maven POMs > Issue Type: Improvement > Components: asf, maven >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-32, MAVEN-42 > > > We have history of releases eg: > [https://maven.apache.org/pom/asf/#history] > [https://maven.apache.org/pom/maven/#history] > [https://maven.apache.org/pom/maven/maven-plugins/#history] > We can replace it by link to GitHub tags/releases and everybody can find what > is interesting for them. > > All of them are manually edited during release preparing. > We should avoid manual steps during release. > Site [https://maven.apache.org/developers/release/parent-pom-release.html] - > should be updated after it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARCHETYPE-657) create target/archetype-it instead of target/classes/archetype-it
Herve Boutemy created ARCHETYPE-657:
---
Summary: create target/archetype-it instead of
target/classes/archetype-it
Key: ARCHETYPE-657
URL: https://issues.apache.org/jira/browse/ARCHETYPE-657
Project: Maven Archetype
Issue Type: Bug
Components: Plugin
Affects Versions: 2.2
Reporter: Herve Boutemy
Fix For: 3.3.0
in ARCHETYPE-389, {{archetype-it}} directory has been created to store
interpolated settings file, which is local to current build
this directory has been created in {{target/classes/}}: should have been in
{{target/}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-657) create target/archetype-it instead of target/classes/archetype-it
[
https://issues.apache.org/jira/browse/ARCHETYPE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-657:
Affects Version/s: 3.2.1
> create target/archetype-it instead of target/classes/archetype-it
> -
>
> Key: ARCHETYPE-657
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-657
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.2, 3.2.1
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.3.0
>
>
> in ARCHETYPE-389, {{archetype-it}} directory has been created to store
> interpolated settings file, which is local to current build
> this directory has been created in {{target/classes/}}: should have been in
> {{target/}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-622) maven-archetype-plugin integration-test doesn't use Maven settings from the main build
[
https://issues.apache.org/jira/browse/ARCHETYPE-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-622:
Description:
Hi,
I would like to raise an issue for the [Maven Archetype Plugin integration-test
goal|https://maven.apache.org/archetype/maven-archetype-plugin/integration-test-mojo.html].
When I execute the plugin with integration-test goal, I would expect that it
would continue using maven settings from the main build unless otherwise
specified. This is how Maven Invoker Plugin already behaves and because of
this, there is inconsistency between the two. Currently the archetype plugin
either uses no settings (the inner Maven build is ran as if without *-s*
option) or uses settings.xml file provided via *settingsFile* config option or
*archetype.test.settingsFile* property.
The issue here is, if a user wants to always propagate settings from the Maven
build (invoker default), it does not always work. There are basically 2 options:
1. Permanently add *settingsFile* reference to the POM file like this:
{code:xml}
${session.request.userSettingsFile.path}{code}
Which will use the path from settings.xml provided to the main build. The issue
with this approach is that in case a user doesn't provide the *-s* option, the
maven invoker will fail saying that ${user.home}/.m2/settings.xml doesn't exist
because by default Maven doesn't create this file with default installation,
i.e. it is not mandatory. So there is no way to satisfy both use cases (pass
the settings of the main build with and without *-s* option specified).
OR
2. Explicitly set *archetype.test.settingsFile* from the command line in case a
user is going to specify the *-s* option with the same value. In case a user is
not going to provide the *-s* option, don't set the property from command line.
This is again not ideal as we need to remember to specify that one property if
and only if *-s* is specified.
So far we have done a workaround which will dump the current Maven settings to
a file with the help of the
[effective-settings|https://maven.apache.org/plugins/maven-help-plugin/effective-settings-mojo.html]
goal of the maven-help-plugin and then we reference it using the
*settingsFile* config option of the archetype plugin.
The main issue I see is that this doesn't work as the maven invoker plugin,
although the functionality is the same - run integration tests on another
project. Invoker plugin by default takes the settings from the main build,
unless overridden. On the other hand, archetype plugin takes either nothing
(i.e. will use default settings, different from the main build), or an
[external
settings.xml|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/IntegrationTestMojo.java#L666-L681].
was:
Hi,
I would like to raise an issue for the Maven Archetype Plugin integration-test
goal. When I execute the plugin with integration-test goal, I would expect that
it would continue using maven settings from the main build unless otherwise
specified. This is how Maven Invoker Plugin already behaves and because of
this, there is inconsistency between the two. Currently the archetype plugin
either uses no settings (the inner Maven build is ran as if without *-s*
option) or uses settings.xml file provided via *settingsFile* config option or
*archetype.test.settingsFile* property.
The issue here is, if a user wants to always propagate settings from the Maven
build (invoker default), it does not always work. There are basically 2 options:
1. Permanently add *settingsFile* reference to the POM file like this:
{code:xml}
${session.request.userSettingsFile.path}{code}
Which will use the path from settings.xml provided to the main build. The issue
with this approach is that in case a user doesn't provide the *-s* option, the
maven invoker will fail saying that ${user.home}/.m2/settings.xml doesn't exist
because by default Maven doesn't create this file with default installation,
i.e. it is not mandatory. So there is no way to satisfy both use cases (pass
the settings of the main build with and without *-s* option specified).
OR
2. Explicitly set *archetype.test.settingsFile* from the command line in case a
user is going to specify the *-s* option with the same value. In case a user is
not going to provide the *-s* option, don't set the property from command line.
This is again not ideal as we need to remember to specify that one property if
and only if *-s* is specified.
So far we have done a workaround which will dump the current Maven settings to
a file with the help of the
[effective-settings|https://maven.apache.org/plugins/maven-help-plugin/effective-settings-mojo.html]
goal of the maven-help-plugin and then we reference it using the
*settingsFile* config option of the archetype plugin.
The main issue I see is that
[jira] [Updated] (MARTIFACT-60) artifact:3.5.0:check-buildplan is too chatty by default
[
https://issues.apache.org/jira/browse/MARTIFACT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MARTIFACT-60:
---
Affects Version/s: 3.5.1
> artifact:3.5.0:check-buildplan is too chatty by default
> ---
>
> Key: MARTIFACT-60
> URL: https://issues.apache.org/jira/browse/MARTIFACT-60
> Project: Maven Artifact Plugin
> Issue Type: Improvement
> Components: artifact:check-buildplan
>Affects Versions: 3.5.0, 3.5.1
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\java\apache-maven-3.9.6
> Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program
> Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Priority: Major
>
> Running the plugin is too chatty by default, for example, I don't need
> everything that's NOT wrong. Just tell me what's wrong or nothing:
> {noformat}
> [INFO] — artifact:3.5.0:check-buildplan (check-buildplan) @ commons-io —
> [INFO] no known issue with
> org.apache.maven.plugins:maven-enforcer-plugin:3.4.1
> [INFO] no known issue with org.apache.rat:apache-rat-plugin:0.16.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-artifact-plugin:3.5.0
> [INFO] no known issue with org.codehaus.mojo:build-helper-maven-plugin:3.5.0
> [INFO] no known issue with org.apache.maven.plugins:maven-antrun-plugin:3.1.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0 (>= 1.7.0)
> [INFO] no known issue with org.codehaus.mojo:buildnumber-maven-plugin:3.2.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-resources-plugin:3.3.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-compiler-plugin:3.13.0
> [INFO] no known issue with org.apache.felix:maven-bundle-plugin:5.1.9 (>=
> 5.1.9)
> [INFO] no known issue with org.jacoco:jacoco-maven-plugin:0.8.11
> [INFO] no known issue with
> org.apache.maven.plugins:maven-surefire-plugin:3.2.5
> [INFO] no known issue with org.apache.maven.plugins:maven-jar-plugin:3.3.0
> (>= 3.2.0)
> [INFO] no known issue with org.apache.maven.plugins:maven-site-plugin:3.12.1
> [INFO] no known issue with org.apache.maven.plugins:maven-source-plugin:3.2.1
> (>= 3.2.1)
> [INFO] no known issue with org.cyclonedx:cyclonedx-maven-plugin:2.8.0
> [INFO] no known issue with org.spdx:spdx-maven-plugin:0.7.3
> [INFO] no known issue with org.moditect:moditect-maven-plugin:1.2.1.Final (>=
> 1.0.0.Final)
> [INFO] no known issue with org.apache.maven.plugins:maven-install-plugin:3.1.1
> [INFO] no known issue with org.apache.maven.plugins:maven-deploy-plugin:3.1.1
> {noformat}
> Either say nothing or, if you must, perhaps a single log event:
> "No issues found in 16 plugins." Note that sentences should start with a
> capital letter.
> The current info would be fine at the debug logging level IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MARTIFACT-60) artifact:3.5.0:check-buildplan is too chatty by default
[
https://issues.apache.org/jira/browse/MARTIFACT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833829#comment-17833829
]
Herve Boutemy commented on MARTIFACT-60:
I feel people bind this goal in their normal build lifecycle, in which case I
understand it is found very chatty
when I wrote it, this goal has been intended for CLI use, as checking on every
build does not make much sense to me: this goal was written to do the first
Reproducible Builds activation easily with fast CLI feedback and fix
easy-fixable issues in pom.xml immediately. Once it's done, remaining issues
are much more precise than just a plugin version: this goal won't help much any
more, only comparison and human dive into "why is there a difference?", with a
human brain to track root cause.
I'm not clear if we should fight the lifecycle bound approach: what I've learn
over time is that fighting users is a lost game, users are too many, it's much
easier to adapt a little bit when it's not hard = this case.
perhaps this is a natural expectation from users: I must admit that even in my
expected CLI usage, seeing a wide list of non-problems makes it hard to dive.
Making by default a summary and eventually a verbose option makes sense
(in addition, when I wrote the goal, "mvn builplan:list" was not well known, I
needed to show even to myself that this goal was filtering on this list:
nowadays, this goal is well know to everybody, my intent is probably not valid
any more)
+1 to do that
> artifact:3.5.0:check-buildplan is too chatty by default
> ---
>
> Key: MARTIFACT-60
> URL: https://issues.apache.org/jira/browse/MARTIFACT-60
> Project: Maven Artifact Plugin
> Issue Type: Improvement
> Components: artifact:check-buildplan
>Affects Versions: 3.5.0
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\java\apache-maven-3.9.6
> Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program
> Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Priority: Major
>
> Running the plugin is too chatty by default, for example, I don't need
> everything that's NOT wrong. Just tell me what's wrong or nothing:
> {noformat}
> [INFO] — artifact:3.5.0:check-buildplan (check-buildplan) @ commons-io —
> [INFO] no known issue with
> org.apache.maven.plugins:maven-enforcer-plugin:3.4.1
> [INFO] no known issue with org.apache.rat:apache-rat-plugin:0.16.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-artifact-plugin:3.5.0
> [INFO] no known issue with org.codehaus.mojo:build-helper-maven-plugin:3.5.0
> [INFO] no known issue with org.apache.maven.plugins:maven-antrun-plugin:3.1.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0 (>= 1.7.0)
> [INFO] no known issue with org.codehaus.mojo:buildnumber-maven-plugin:3.2.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-resources-plugin:3.3.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-compiler-plugin:3.13.0
> [INFO] no known issue with org.apache.felix:maven-bundle-plugin:5.1.9 (>=
> 5.1.9)
> [INFO] no known issue with org.jacoco:jacoco-maven-plugin:0.8.11
> [INFO] no known issue with
> org.apache.maven.plugins:maven-surefire-plugin:3.2.5
> [INFO] no known issue with org.apache.maven.plugins:maven-jar-plugin:3.3.0
> (>= 3.2.0)
> [INFO] no known issue with org.apache.maven.plugins:maven-site-plugin:3.12.1
> [INFO] no known issue with org.apache.maven.plugins:maven-source-plugin:3.2.1
> (>= 3.2.1)
> [INFO] no known issue with org.cyclonedx:cyclonedx-maven-plugin:2.8.0
> [INFO] no known issue with org.spdx:spdx-maven-plugin:0.7.3
> [INFO] no known issue with org.moditect:moditect-maven-plugin:1.2.1.Final (>=
> 1.0.0.Final)
> [INFO] no known issue with org.apache.maven.plugins:maven-install-plugin:3.1.1
> [INFO] no known issue with org.apache.maven.plugins:maven-deploy-plugin:3.1.1
> {noformat}
> Either say nothing or, if you must, perhaps a single log event:
> "No issues found in 16 plugins." Note that sentences should start with a
> capital letter.
> The current info would be fine at the debug logging level IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7344) Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7344: --- Description: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the "resolution path" to that element. Until now, only the usual pure inheritance is tracked though InputLocation, as done in MNG-1803, later displayed by verbose help effective-pom with MPH-160 The following are known to add elements to the effective pom: - BOMs dependencyManagement import - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] Without this feature, it is very hard to detect where these extra elements are coming from. was: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the "resolution path" to that element. Until now, only the usual pure inheritance is tracked though InputLocation, as done in MNG-1803 The following are known to add elements to the effective pom: - BOMs dependencyManagement import - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] Without this feature, it is very hard to detect where these extra elements are coming from. > Effective pom should contain more finegrained details regarding its content > origin: track dependencyManagement import > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Fix For: 3.9.x-candidate, 4.0.x-candidate > > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the "resolution path" to that element. > Until now, only the usual pure inheritance is tracked though InputLocation, > as done in MNG-1803, later displayed by verbose help effective-pom with > MPH-160 > The following are known to add elements to the effective pom: > - BOMs dependencyManagement import > - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] > Without this feature, it is very hard to detect where these extra elements > are coming from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7344) Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7344: --- Description: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the "resolution path" to that element. Until now, only the usual pure inheritance is tracked though InputLocation, as done in MNG-1803 The following are known to add elements to the effective pom: - BOMs dependencyManagement import - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] Without this feature, it is very hard to detect where these extra elements are coming from. was: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the "resolution path" to that element. Until now, only the usual pure inheritance is tracked though InputLocation The following are known to add elements to the effective pom: - BOMs dependencyManagement import - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] Without this feature, it is very hard to detect where these extra elements are coming from. > Effective pom should contain more finegrained details regarding its content > origin: track dependencyManagement import > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Fix For: 3.9.x-candidate, 4.0.x-candidate > > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the "resolution path" to that element. > Until now, only the usual pure inheritance is tracked though InputLocation, > as done in MNG-1803 > The following are known to add elements to the effective pom: > - BOMs dependencyManagement import > - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] > Without this feature, it is very hard to detect where these extra elements > are coming from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7344) Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7344: --- Description: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the "resolution path" to that element. Until now, only the usual pure inheritance is tracked though InputLocation The following are known to add elements to the effective pom: - BOMs dependencyManagement import - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] Without this feature, it is very hard to detect where these extra elements are coming from. was: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the "resolution path" to that element. Until now, only the usual pure inheritance is tracked The following are known to add elements to the effective pom: - BOMs dependencyManagement import - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] Without this feature, it is very hard to detect where these extra elements are coming from. > Effective pom should contain more finegrained details regarding its content > origin: track dependencyManagement import > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Fix For: 3.9.x-candidate, 4.0.x-candidate > > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the "resolution path" to that element. > Until now, only the usual pure inheritance is tracked though InputLocation > The following are known to add elements to the effective pom: > - BOMs dependencyManagement import > - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] > Without this feature, it is very hard to detect where these extra elements > are coming from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8004) Enhance location tracking
[ https://issues.apache.org/jira/browse/MNG-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832556#comment-17832556 ] Herve Boutemy commented on MNG-8004: yes, duplicates MNG-7344 > Enhance location tracking > - > > Key: MNG-8004 > URL: https://issues.apache.org/jira/browse/MNG-8004 > Project: Maven > Issue Type: Task > Components: Core >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.x-candidate, 4.0.0 > > > So far location tracking gives us source file, line num and col num, which is > fine. > But historically, Maven2 had only parent POMs, Maven3 introduced import POMs, > while Maven4 will have things like XInclude as well. > It would be great if we could enhance location with 4th element: "why (or > how) did this element end up here". Was it from current POM, from parent > maybe? From import-pom? Or was it XIncluded? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7344) Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7344: --- Fix Version/s: 3.9.x-candidate > Effective pom should contain more finegrained details regarding its content > origin: track dependencyManagement import > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Fix For: 3.9.x-candidate, 4.0.x-candidate > > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the "resolution path" to that element. > Until now, only the usual pure inheritance is tracked > The following are known to add elements to the effective pom: > - BOMs dependencyManagement import > - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] > Without this feature, it is very hard to detect where these extra elements > are coming from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7344) Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7344: --- Description: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the "resolution path" to that element. Until now, only the usual pure inheritance is tracked The following are known to add elements to the effective pom: - BOMs dependencyManagement import - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] Without this feature, it is very hard to detect where these extra elements are coming from. was: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the "resolution path" to that element. The following are known to add elements to the effective pom: - the usual pure inheritance - BOMs dependencyManagement import - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] Without this feature, it is very hard to detect where these extra elements are coming from. > Effective pom should contain more finegrained details regarding its content > origin: track dependencyManagement import > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Fix For: 4.0.x-candidate > > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the "resolution path" to that element. > Until now, only the usual pure inheritance is tracked > The following are known to add elements to the effective pom: > - BOMs dependencyManagement import > - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] > Without this feature, it is very hard to detect where these extra elements > are coming from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7344) Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7344: --- Summary: Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import (was: Effective pom should contain more finegrained details regarding its content origin.) > Effective pom should contain more finegrained details regarding its content > origin: track dependencyManagement import > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Fix For: 4.0.x-candidate > > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the "resolution path" to that element. > The following are known to add elements to the effective pom: > - the usual pure inheritance > - BOMs dependencyManagement import > - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] > Without this feature, it is very hard to detect where these extra elements > are coming from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPH-183) Effective-pom + verbose should show import path to BOM dependencyManagement
[ https://issues.apache.org/jira/browse/MPH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPH-183: -- Description: The popular spring-boot makes a lot of use of BOMs. Using BOMs is a good practice, but right now it is very hard to determine where dependencyManagement dependencies and especially their versions are coming from. Instead of only showing only the final location (from the BOM POM), it should also show the import path from the current project to that specific pom (where is the BOM POM imported?). This way it will be easier to figure out which dependency in which POM needs to be upgraded: it's the version in the POM declaring the import of the BOM POM, not the version in the imported BOM POM. was: The popular spring-boot makes a lot of use of BOMs. Using BOMs is a good practice, but right now it is very hard to determine where dependencies and especially their versions are coming from. Instead of only showing only the final location (from the BOM POM), it should also show the import path from the current project to that specific pom (where is the BOM POM imported?). This way it will be easier to figure out which dependency in which POM needs to be upgraded: it's the version in the POM declaring the import of the BOM POM, not the version in the imported BOM POM. > Effective-pom + verbose should show import path to BOM dependencyManagement > --- > > Key: MPH-183 > URL: https://issues.apache.org/jira/browse/MPH-183 > Project: Maven Help Plugin > Issue Type: Improvement >Affects Versions: 3.2.0 >Reporter: Robert Scholte >Assignee: Maarten Mulders >Priority: Major > Attachments: mph-183-it.zip > > > The popular spring-boot makes a lot of use of BOMs. Using BOMs is a good > practice, but right now it is very hard to determine where > dependencyManagement dependencies and especially their versions are coming > from. > Instead of only showing only the final location (from the BOM POM), it should > also show the import path from the current project to that specific pom > (where is the BOM POM imported?). > This way it will be easier to figure out which dependency in which POM needs > to be upgraded: it's the version in the POM declaring the import of the BOM > POM, not the version in the imported BOM POM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-515) requiresDependencyCollection configuration does not get documented
[ https://issues.apache.org/jira/browse/MPLUGIN-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-515: -- Priority: Minor (was: Major) > requiresDependencyCollection configuration does not get documented > -- > > Key: MPLUGIN-515 > URL: https://issues.apache.org/jira/browse/MPLUGIN-515 > Project: Maven Plugin Tools > Issue Type: Bug >Affects Versions: 3.12.0 >Reporter: Herve Boutemy >Priority: Minor > Labels: up-for-grabs > > see > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/collect-mojo.html > corresponds to > https://github.com/apache/maven-dependency-plugin/blob/maven-dependency-plugin-3.6.1/src/main/java/org/apache/maven/plugins/dependency/resolvers/CollectDependenciesMojo.java#L46 > classical requiresDependencyResolution is perfectly documented like > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/resolve-mojo.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-515) requiresDependencyCollection configuration does not get documented
[ https://issues.apache.org/jira/browse/MPLUGIN-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-515: -- Component/s: Plugin Reporting Plugin > requiresDependencyCollection configuration does not get documented > -- > > Key: MPLUGIN-515 > URL: https://issues.apache.org/jira/browse/MPLUGIN-515 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Reporting Plugin >Affects Versions: 3.12.0 >Reporter: Herve Boutemy >Priority: Minor > Labels: up-for-grabs > > see > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/collect-mojo.html > corresponds to > https://github.com/apache/maven-dependency-plugin/blob/maven-dependency-plugin-3.6.1/src/main/java/org/apache/maven/plugins/dependency/resolvers/CollectDependenciesMojo.java#L46 > classical requiresDependencyResolution is perfectly documented like > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/resolve-mojo.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-515) requiresDependencyCollection configuration does not get documented
[ https://issues.apache.org/jira/browse/MPLUGIN-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-515: -- Affects Version/s: 3.12.0 > requiresDependencyCollection configuration does not get documented > -- > > Key: MPLUGIN-515 > URL: https://issues.apache.org/jira/browse/MPLUGIN-515 > Project: Maven Plugin Tools > Issue Type: Bug >Affects Versions: 3.12.0 >Reporter: Herve Boutemy >Priority: Major > Labels: up-for-grabs > > see > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/collect-mojo.html > corresponds to > https://github.com/apache/maven-dependency-plugin/blob/maven-dependency-plugin-3.6.1/src/main/java/org/apache/maven/plugins/dependency/resolvers/CollectDependenciesMojo.java#L46 > classical requiresDependencyResolution is perfectly documented like > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/resolve-mojo.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-515) requiresDependencyCollection configuration does not get documented
[ https://issues.apache.org/jira/browse/MPLUGIN-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-515: -- Labels: up-for-grabs (was: ) > requiresDependencyCollection configuration does not get documented > -- > > Key: MPLUGIN-515 > URL: https://issues.apache.org/jira/browse/MPLUGIN-515 > Project: Maven Plugin Tools > Issue Type: Bug >Reporter: Herve Boutemy >Priority: Major > Labels: up-for-grabs > > see > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/collect-mojo.html > corresponds to > https://github.com/apache/maven-dependency-plugin/blob/maven-dependency-plugin-3.6.1/src/main/java/org/apache/maven/plugins/dependency/resolvers/CollectDependenciesMojo.java#L46 > classical requiresDependencyResolution is perfectly documented like > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/resolve-mojo.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-515) requiresDependencyCollection configuration does not get documented
Herve Boutemy created MPLUGIN-515: - Summary: requiresDependencyCollection configuration does not get documented Key: MPLUGIN-515 URL: https://issues.apache.org/jira/browse/MPLUGIN-515 Project: Maven Plugin Tools Issue Type: Bug Reporter: Herve Boutemy see https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/collect-mojo.html corresponds to https://github.com/apache/maven-dependency-plugin/blob/maven-dependency-plugin-3.6.1/src/main/java/org/apache/maven/plugins/dependency/resolvers/CollectDependenciesMojo.java#L46 classical requiresDependencyResolution is perfectly documented like https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/resolve-mojo.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MDEP-914) collect goal description broken in documentation
[ https://issues.apache.org/jira/browse/MDEP-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MDEP-914: --- Labels: up-for-grabs (was: ) > collect goal description broken in documentation > > > Key: MDEP-914 > URL: https://issues.apache.org/jira/browse/MDEP-914 > Project: Maven Dependency Plugin > Issue Type: Task > Components: collect >Affects Versions: 3.6.1 >Reporter: Herve Boutemy >Priority: Major > Labels: up-for-grabs > > https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/collect-mojo.html > says "It is identicat to ??? except" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-914) collect goal description broken in documentation
Herve Boutemy created MDEP-914: -- Summary: collect goal description broken in documentation Key: MDEP-914 URL: https://issues.apache.org/jira/browse/MDEP-914 Project: Maven Dependency Plugin Issue Type: Task Components: collect Affects Versions: 3.6.1 Reporter: Herve Boutemy https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/collect-mojo.html says "It is identicat to ??? except" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-913) dependency:collect missing from index page
Herve Boutemy created MDEP-913: -- Summary: dependency:collect missing from index page Key: MDEP-913 URL: https://issues.apache.org/jira/browse/MDEP-913 Project: Maven Dependency Plugin Issue Type: Task Components: collect Affects Versions: 3.6.1 Reporter: Herve Boutemy listed in https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/plugin-info.html but not https://maven.apache.org/plugins-archives/maven-dependency-plugin-3.6.1/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (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:all-tabpanel ] Herve Boutemy updated MPLUGIN-508: -- Affects Version/s: 3.12.0 > 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 >Affects Versions: 3.12.0 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.12.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (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:all-tabpanel ] Herve Boutemy updated MPLUGIN-508: -- Fix Version/s: (was: 3.12.0) > 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 >Affects Versions: 3.12.0 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSOURCES-140) Build fails when using install deploy
[ https://issues.apache.org/jira/browse/MSOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSOURCES-140: --- Fix Version/s: next-release (was: 3.3.1) > Build fails when using install deploy > - > > Key: MSOURCES-140 > URL: https://issues.apache.org/jira/browse/MSOURCES-140 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Joern >Priority: Minor > Fix For: next-release > > > By configuration maven-source-plugin is bound to verify phase. > When executing commands like mvn install deploy, which includes phase verify > 2 times, the build fails with error "We have duplicated artifacts attached." > - it worked with 3.2.1 > When just using mvn deploy it works. > I know install and deploy together are redundant but in many build pipelines > it is used that way and maven as such also allows the combination. > Probably caused by MSOURCES-121 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MARTIFACT-59) artifact plugin should tolerate injected project.build.outputTimestamp
[ https://issues.apache.org/jira/browse/MARTIFACT-59 ]
Herve Boutemy deleted comment on MARTIFACT-59:
was (Author: hboutemy):
notice that MARTIFACT-54 was causing unwanted check-buildplan failure
please check with 3.5.1: you should not get the failure on "mvn
artifact:3.5.1:check-buildplan" that happened with "mvn
artifact:3.5.0:check-buildplan"
> artifact plugin should tolerate injected project.build.outputTimestamp
> --
>
> Key: MARTIFACT-59
> URL: https://issues.apache.org/jira/browse/MARTIFACT-59
> Project: Maven Artifact Plugin
> Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Priority: Minor
> Labels: pull-request-available
>
> Goal is to not log
> {code:java}
> Reproducible Build not activated by project.build.outputTimestamp property:
> see https://maven.apache.org/guides/mini/guide-reproducible-builds.html {code}
> when the project is actually set but computed from another property and not
> fail (check mojo) when the setup is the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MARTIFACT-59) artifact plugin should tolerate injected project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MARTIFACT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832342#comment-17832342
]
Herve Boutemy commented on MARTIFACT-59:
notice that MARTIFACT-54 was causing unwanted check-buildplan failure
please check with 3.5.1: you should not get the failure on "mvn
artifact:3.5.1:check-buildplan" that happened with "mvn
artifact:3.5.0:check-buildplan"
> artifact plugin should tolerate injected project.build.outputTimestamp
> --
>
> Key: MARTIFACT-59
> URL: https://issues.apache.org/jira/browse/MARTIFACT-59
> Project: Maven Artifact Plugin
> Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Priority: Minor
> Labels: pull-request-available
>
> Goal is to not log
> {code:java}
> Reproducible Build not activated by project.build.outputTimestamp property:
> see https://maven.apache.org/guides/mini/guide-reproducible-builds.html {code}
> when the project is actually set but computed from another property and not
> fail (check mojo) when the setup is the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MARTIFACT-53) improve message when outputTimestamp not defined in reactor: WARN only
[
https://issues.apache.org/jira/browse/MARTIFACT-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MARTIFACT-53:
---
Component/s: artifact:buildinfo
artifact:compare
> improve message when outputTimestamp not defined in reactor: WARN only
> --
>
> Key: MARTIFACT-53
> URL: https://issues.apache.org/jira/browse/MARTIFACT-53
> Project: Maven Artifact Plugin
> Issue Type: Improvement
> Components: artifact:buildinfo, artifact:compare
>Affects Versions: 3.3.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.5.1
>
>
> {{[ERROR] project.build.outputTimestamp property should not be inherited but
> defined in POM /var/maven/app/.flattened-pom.xml}}
>
> and don't fail check-buildplan
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MARTIFACT-54) In multi-module projects check-buildplan fails on project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MARTIFACT-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MARTIFACT-54:
---
Priority: Critical (was: Major)
> In multi-module projects check-buildplan fails on
> project.build.outputTimestamp
> ---
>
> Key: MARTIFACT-54
> URL: https://issues.apache.org/jira/browse/MARTIFACT-54
> Project: Maven Artifact Plugin
> Issue Type: Bug
> Components: artifact:check-buildplan
>Affects Versions: 3.5.0
>Reporter: Niels Basjes
>Assignee: Herve Boutemy
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.5.1
>
>
> Reproduce:
> In an empty directory create a {{pom.xml}} with
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> pom
> nl.basjes.maven
> parent
> 0.0.1-SNAPSHOT
>
>
> 2011-11-11T11:11:11Z
>
>
> child
>
>
> {code}
> create a subdirectory {{child}} and create the file {{child/pom.xml}} with
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>
> nl.basjes.maven
> parent
> 0.0.1-SNAPSHOT
>
> child
>
> {code}
> Now run the 3.4.1 version of the plugin using maven 3.9.4 on Linux under Java
> 17:
> {code:bash}
> $ mvn org.apache.maven.plugins:maven-artifact-plugin:3.4.1:check-buildplan
> {code}
> Summary of the output:
> {code:bash}
> [INFO] parent . SUCCESS [ 0.228
> s]
> [INFO] child .. SUCCESS [ 0.042
> s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> Now repeat the same with the 3.5.0 version of the plugin:
> {code:bash}
> $ mvn org.apache.maven.plugins:maven-artifact-plugin:3.5.0:check-buildplan
> {code}
> Summary of the output:
> {code:bash}
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] parent
> [pom]
> [INFO] child
> [jar]
> ...
> [INFO] ---< nl.basjes.maven:child
> >
> [INFO] Building child 0.0.1-SNAPSHOT
> [2/2]
> [INFO] from child/pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- artifact:3.5.0:check-buildplan (default-cli) @ child ---
> [ERROR] project.build.outputTimestamp property should not be inherited but
> defined in POM
> /home/nbasjes/workspace/Prive/BugReports/CheckBuildPlan/child/pom.xml
> ...
> [INFO] BUILD FAILURE
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7570) Allow a Maven plugin to require a Maven version through its plugin descriptor
[ https://issues.apache.org/jira/browse/MNG-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7570: --- Description: Although the minimum Maven version can be specified via plugin's pom's prerequisites (https://maven.apache.org/pom.html#Prerequisites), there is currently no element for this on the plugin descriptor XML content. I would suggest to slightly expand the plugin descriptor to include an element there as well. If such an element is found it should take precedence over plugin pom prerequisites. was: Although the minimum Maven version can be specified via pom's prerequisites (https://maven.apache.org/pom.html#Prerequisites), there is currently no element for this on the plugin descriptor XML content. I would suggest to slightly expand the plugin descriptor to include an element there as well. If such an element is found it should take precedence over pom prerequisites. > Allow a Maven plugin to require a Maven version through its plugin descriptor > - > > Key: MNG-7570 > URL: https://issues.apache.org/jira/browse/MNG-7570 > Project: Maven > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Labels: plugin-descriptor-1.1 > Fix For: 4.0.0-alpha-3, 4.0.0 > > > Although the minimum Maven version can be specified via plugin's pom's > prerequisites (https://maven.apache.org/pom.html#Prerequisites), there is > currently no element for this on the plugin descriptor XML content. > I would suggest to slightly expand the plugin descriptor to include an > element there as well. If such an element is found it should take precedence > over plugin pom prerequisites. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7570) Allow a Maven plugin to require a Maven version through its plugin descriptor
[ https://issues.apache.org/jira/browse/MNG-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7570: --- Description: Although the minimum Maven version can be specified via pom's prerequisites (https://maven.apache.org/pom.html#Prerequisites), there is currently no element for this on the plugin descriptor XML content. I would suggest to slightly expand the plugin descriptor to include an element there as well. If such an element is found it should take precedence over pom prerequisites. was: Although the minimum Maven version can be specified via pom's prerequisites (https://maven.apache.org/pom.html#Prerequisites), there is currently no element for this on the plugin descriptor. I would suggest to slightly expand the plugin descriptor to include an element there as well. If such an element is found it should take precedence over pom prerequisites. > Allow a Maven plugin to require a Maven version through its plugin descriptor > - > > Key: MNG-7570 > URL: https://issues.apache.org/jira/browse/MNG-7570 > Project: Maven > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Labels: plugin-descriptor-1.1 > Fix For: 4.0.0-alpha-3, 4.0.0 > > > Although the minimum Maven version can be specified via pom's prerequisites > (https://maven.apache.org/pom.html#Prerequisites), there is currently no > element for this on the plugin descriptor XML content. > I would suggest to slightly expand the plugin descriptor to include an > element there as well. If such an element is found it should take precedence > over pom prerequisites. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7570) Allow a Maven plugin to require a Maven version through its plugin descriptor
[ https://issues.apache.org/jira/browse/MNG-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7570: --- Fix Version/s: 4.0.0-alpha-3 > Allow a Maven plugin to require a Maven version through its plugin descriptor > - > > Key: MNG-7570 > URL: https://issues.apache.org/jira/browse/MNG-7570 > Project: Maven > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Labels: plugin-descriptor-1.1 > Fix For: 4.0.0-alpha-3, 4.0.0 > > > Although the minimum Maven version can be specified via pom's prerequisites > (https://maven.apache.org/pom.html#Prerequisites), there is currently no > element for this on the plugin descriptor. > I would suggest to slightly expand the plugin descriptor to include an > element there as well. If such an element is found it should take precedence > over pom prerequisites. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Moved] (MARTIFACT-59) artifact plugin should tolerate injected project.build.outputTimestamp
[ https://issues.apache.org/jira/browse/MARTIFACT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy moved MNG-8077 to MARTIFACT-59: - Key: MARTIFACT-59 (was: MNG-8077) Issue Type: Improvement (was: Task) Project: Maven Artifact Plugin (was: Maven) > artifact plugin should tolerate injected project.build.outputTimestamp > -- > > Key: MARTIFACT-59 > URL: https://issues.apache.org/jira/browse/MARTIFACT-59 > Project: Maven Artifact Plugin > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8085) swtich from png+imagemap to svg
[ https://issues.apache.org/jira/browse/MNG-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-8085. -- Resolution: Fixed > swtich from png+imagemap to svg > --- > > Key: MNG-8085 > URL: https://issues.apache.org/jira/browse/MNG-8085 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.9.6, 4.0.0-alpha-13 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.7, 4.0.0-alpha-14 > > > result = https://maven.apache.org/ref/3-LATEST/ vs previous > https://maven.apache.org/ref/3.9.6/ > and https://maven.apache.org/ref/4-LATEST/ vs previous > https://maven.apache.org/ref/4.0.0-alpha-13/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8085) swtich from png+imagemap to svg
[ https://issues.apache.org/jira/browse/MNG-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-8085: --- Fix Version/s: 4.0.0-alpha-14 > swtich from png+imagemap to svg > --- > > Key: MNG-8085 > URL: https://issues.apache.org/jira/browse/MNG-8085 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.9.6, 4.0.0-alpha-13 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.7, 4.0.0-alpha-14 > > > result = https://maven.apache.org/ref/3-LATEST/ vs previous > https://maven.apache.org/ref/3.9.6/ > and https://maven.apache.org/ref/4-LATEST/ vs previous > https://maven.apache.org/ref/4.0.0-alpha-13/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8085) swtich from png+imagemap to svg
[ https://issues.apache.org/jira/browse/MNG-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-8085: --- Description: result = https://maven.apache.org/ref/3-LATEST/ vs previous https://maven.apache.org/ref/3.9.6/ and https://maven.apache.org/ref/4-LATEST/ vs previous https://maven.apache.org/ref/4.0.0-alpha-13/ was:result = https://maven.apache.org/ref/3-LATEST/ vs previous https://maven.apache.org/ref/3.9.6/ > swtich from png+imagemap to svg > --- > > Key: MNG-8085 > URL: https://issues.apache.org/jira/browse/MNG-8085 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.9.6, 4.0.0-alpha-13 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.7 > > > result = https://maven.apache.org/ref/3-LATEST/ vs previous > https://maven.apache.org/ref/3.9.6/ > and https://maven.apache.org/ref/4-LATEST/ vs previous > https://maven.apache.org/ref/4.0.0-alpha-13/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8085) swtich from png+imagemap to svg
[ https://issues.apache.org/jira/browse/MNG-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-8085: --- Description: result = https://maven.apache.org/ref/3-LATEST/ vs previous https://maven.apache.org/ref/3.9.6/ > swtich from png+imagemap to svg > --- > > Key: MNG-8085 > URL: https://issues.apache.org/jira/browse/MNG-8085 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.9.6, 4.0.0-alpha-13 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.7 > > > result = https://maven.apache.org/ref/3-LATEST/ vs previous > https://maven.apache.org/ref/3.9.6/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8085) swtich from png+imagemap to svg
Herve Boutemy created MNG-8085: -- Summary: swtich from png+imagemap to svg Key: MNG-8085 URL: https://issues.apache.org/jira/browse/MNG-8085 Project: Maven Issue Type: Improvement Components: Documentation: General Affects Versions: 4.0.0-alpha-13, 3.9.6 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.9.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (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 closed MPLUGIN-510. - Assignee: Herve Boutemy Resolution: Fixed > 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 >Assignee: 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] [Comment Edited] (MARTIFACT-58) display origin of local repository artifact when comparing
[ https://issues.apache.org/jira/browse/MARTIFACT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808920#comment-17808920 ] Herve Boutemy edited comment on MARTIFACT-58 at 3/23/24 7:10 AM: - notice that the info was removed from maven-project-info-reports-plugin MPIR-367 when cleaning code for Maven 3 because the code was not giving trust worthy results when users has a MRM perhaps this is not a problem in the current case because it's an info that is expected to be used locally instead of being published... was (Author: hboutemy): notice that the info was removed from maven-project-info-reports-plugin MPIR-367 when cleaning code for Maven 3 because the code was not giving good results perhaps this is not a problem in the current case because it's an info that is expected to be used locally instead of being published... > display origin of local repository artifact when comparing > -- > > Key: MARTIFACT-58 > URL: https://issues.apache.org/jira/browse/MARTIFACT-58 > Project: Maven Artifact Plugin > Issue Type: Wish > Components: artifact:compare >Affects Versions: 3.5.0 >Reporter: Herve Boutemy >Priority: Major > > artifact:compare compares output from current build (available in target/) to > content from local repository > what is not easy to detect is if content from local repository comes from a > previous local "mvn install" (done recently or a long time ago) or if it was > downloaded from a remote repository > perhaps the artifact:compare can detect and display the info -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPLUGIN-514) switch dependency schema from png + imagemap to svg, and update
[ https://issues.apache.org/jira/browse/MPLUGIN-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPLUGIN-514. - Resolution: Fixed > switch dependency schema from png + imagemap to svg, and update > --- > > Key: MPLUGIN-514 > URL: https://issues.apache.org/jira/browse/MPLUGIN-514 > Project: Maven Plugin Tools > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > makes updates much easier: hyperlink can be added to source .odf file > then export to svg (select all then limit export to selection) in root > directory > then run ./prepare-svg.sh > requires install of svgo to rework the svg exported by LibreOffice: > https://svgo.dev/ > result published to > https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/ > vs initial png > https://maven.apache.org/plugin-tools-archives/plugin-tools-3.11.0/ > also updating for part changes: introduction of maven-plugin-report-plugin, > removal of javadoc doclet, deprecation of script -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-514) switch dependency schema from png + imagemap to svg, and update
Herve Boutemy created MPLUGIN-514: - Summary: switch dependency schema from png + imagemap to svg, and update Key: MPLUGIN-514 URL: https://issues.apache.org/jira/browse/MPLUGIN-514 Project: Maven Plugin Tools Issue Type: Improvement Affects Versions: 3.11.0 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.12.0 makes updates much easier: hyperlink can be added to source .odf file then export to svg (select all then limit export to selection) in root directory then run ./prepare-svg.sh requires install of svgo to rework the svg exported by LibreOffice: https://svgo.dev/ result published to https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/ vs initial png https://maven.apache.org/plugin-tools-archives/plugin-tools-3.11.0/ also updating for part changes: introduction of maven-plugin-report-plugin, removal of javadoc doclet, deprecation of script -- 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=17827864#comment-17827864
]
Herve Boutemy commented on MNG-8076:
based on discussions: the fact that central repository is declared as
updatePolicy=never, it seems it is the reason why verification is not done
still need to check
> 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] [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] (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] [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] [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] [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] [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] [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)
[jira] [Commented] (DOXIA-734) anchor element with "name" attribute no longer detected by XdocParser/FmlParser
[
https://issues.apache.org/jira/browse/DOXIA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827437#comment-17827437
]
Herve Boutemy commented on DOXIA-734:
-
{quote}Herve Boutemy, I do remember that you told me that there is no effort in
keeping FML, and there is basically none. Now you think it is time to remove?
If so, we should deprecate in this milestone and drop in the next one.{quote}
Yes, I confirm what I told: I'm just ok to drop if some people want to drop
something, I don't want to fight on every tiny front, and FML looks like a tiny
front
on FML, I'll follow what you decide: very small impact on users, very small
impact on maintenance, just choose
The xdoc discussion is much more important: I need more time to review your
discussions, because now I understand it is more about xdoc 2 vs xdoc 3, not
really about fully dropping xdoc
I don't have serious time to read for now, but I hope I'll do this WE
xdoc is a serious front where we need to measure the impacts of any choice we
do: yes, maybe we'll have hard choice to do
> anchor element with "name" attribute 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
>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] [Commented] (DOXIA-734) anchor element with "name" attribute no longer detected by XdocParser/FmlParser
[
https://issues.apache.org/jira/browse/DOXIA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826971#comment-17826971
]
Herve Boutemy commented on DOXIA-734:
-
FML is legacy, and even when not legacy, it was an edge case not used so much
xdoc is the XML view on the Sink API: by definition, to me, it cannot be legacy
as it just translates the Sink API into an XML source syntax: if someone wants
to use the pure Doxia API = the sink API, xdoc remains the way to go
ok, this use case remains an edge case, as nowadays people should prefer
Markdown or asciidoc, but Markdown and asciidoc are a mix between Doxia Sink
API supported features and raw HTML parsing / immediate rendering: having xdoc
remains useful as a reminder (if my view still makes sense: over years, maybe
I'm wrong now...)
in summary: ok to drop FML, not ok to drop xdoc
> anchor element with "name" attribute 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
>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] (MGPG-102) Drop maven-artifact-transfer used by sign-and-deploy-file
[ https://issues.apache.org/jira/browse/MGPG-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MGPG-102: --- Summary: Drop maven-artifact-transfer used by sign-and-deploy-file (was: Drop maven-artifact-transfer) > Drop maven-artifact-transfer used by sign-and-deploy-file > - > > Key: MGPG-102 > URL: https://issues.apache.org/jira/browse/MGPG-102 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRRESOURCES-143) Maven 3.6.3 as minimum requirements
[ https://issues.apache.org/jira/browse/MRRESOURCES-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822910#comment-17822910 ] Herve Boutemy commented on MRRESOURCES-143: --- please document requirements history when doing such a requirement change > Maven 3.6.3 as minimum requirements > --- > > Key: MRRESOURCES-143 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-143 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MRRESOURCES-143) Maven 3.6.3 as minimum requirements
[ https://issues.apache.org/jira/browse/MRRESOURCES-143 ] Herve Boutemy deleted comment on MRRESOURCES-143: --- was (Author: hboutemy): please document requirements history when doing such a requirement change > Maven 3.6.3 as minimum requirements > --- > > Key: MRRESOURCES-143 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-143 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1214) SVN tag in pom.xml
[
https://issues.apache.org/jira/browse/MSHARED-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822907#comment-17822907
]
Herve Boutemy commented on MSHARED-1214:
it seems there has been a bug in a past release of maven-release-plugin: see
OAK-10662 for explanation in the context of another project hit
> SVN tag in pom.xml
> --
>
> Key: MSHARED-1214
> URL: https://issues.apache.org/jira/browse/MSHARED-1214
> Project: Maven Shared Components
> Issue Type: Dependency upgrade
> Components: maven-filtering
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Fix For: maven-filtering-3.3.2
>
>
> Although the current release version is 3.3.1 I see this in pm.xml at head:
> ```
>
>
> scm:git:https://gitbox.apache.org/repos/asf/maven-filtering.git
>
> scm:git:https://gitbox.apache.org/repos/asf/maven-filtering.git
> maven-filtering-3.2.0
>
> https://github.com/apache/maven-filtering/tree/${project.scm.tag}
>
> ```
> Probably we should just detag this info since it isn't kept up to date and
> simply point to head like most projects do.
--
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: -- Summary: create and share tooling to detect plugin prerequisites history (was: create and share tooling to detect plugin prerequsites history) > 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)
[jira] [Updated] (MARTIFACT-58) display origin of local repository artifact when comparing
[ https://issues.apache.org/jira/browse/MARTIFACT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MARTIFACT-58: --- Labels: (was: up-for-grabs) > display origin of local repository artifact when comparing > -- > > Key: MARTIFACT-58 > URL: https://issues.apache.org/jira/browse/MARTIFACT-58 > Project: Maven Artifact Plugin > Issue Type: Wish > Components: artifact:compare >Affects Versions: 3.5.0 >Reporter: Herve Boutemy >Priority: Major > > artifact:compare compares output from current build (available in target/) to > content from local repository > what is not easy to detect is if content from local repository comes from a > previous local "mvn install" (done recently or a long time ago) or if it was > downloaded from a remote repository > perhaps the artifact:compare can detect and display the info -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MWAR-471) normalize file permissions on dependencies copied to WEB-INF/lib
[ https://issues.apache.org/jira/browse/MWAR-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820395#comment-17820395 ] Herve Boutemy edited comment on MWAR-471 at 2/25/24 8:28 AM: - bq. building on Windows with WLS sharing a disk with for the local repository with the Windows machine I suppose it's the same when you mount a smb disk, that does not track Unix permissions: there is a common permission assigned https://sysadmins.tech/linux-and-cifs-files-permissions/ was (Author: hboutemy): bq. building on Windows with WLS sharing a disk with for the local repository with the Windows machine I suppose it's the same when you mount a smb disk, that does not track Unix permissions: there is a common permission assigned > normalize file permissions on dependencies copied to WEB-INF/lib > > > Key: MWAR-471 > URL: https://issues.apache.org/jira/browse/MWAR-471 > Project: Maven WAR Plugin > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Herve Boutemy >Priority: Major > > as seen on Jackrabbit releases > https://lists.apache.org/thread/6qxnclwmxggq6j20l8z78yr375vxo508, building on > Windows with WLS sharing a disk with for the local repository with the > Windows machine leads to executable permission on dependency jars copied to > WEB-INF/lib > normalizing permissions during the copy from local repo to WEB-INF/lib looks > reasonable to solve that environment edge case -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWAR-471) normalize file permissions on dependencies copied to WEB-INF/lib
[ https://issues.apache.org/jira/browse/MWAR-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWAR-471: --- Description: as seen on Jackrabbit releases https://lists.apache.org/thread/6qxnclwmxggq6j20l8z78yr375vxo508, building on Windows with WLS sharing a disk with for the local repository with the Windows machine leads to executable permission on dependency jars copied to WEB-INF/lib normalizing permissions during the copy from local repo to WEB-INF/lib looks reasonable to solve that environment edge case was: as seen on Jackrabbit releases https://lists.apache.org/thread/6qxnclwmxggq6j20l8z78yr375vxo508, building on Windows with WSL sharing a disk with for the local repository with the Windows machine leads to executable permission on dependency jars copied to WEB-INF/lib normalizing permissions during the copy from local repo to WEB-INF/lib looks reasonable to solve that environment edge case > normalize file permissions on dependencies copied to WEB-INF/lib > > > Key: MWAR-471 > URL: https://issues.apache.org/jira/browse/MWAR-471 > Project: Maven WAR Plugin > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Herve Boutemy >Priority: Major > > as seen on Jackrabbit releases > https://lists.apache.org/thread/6qxnclwmxggq6j20l8z78yr375vxo508, building on > Windows with WLS sharing a disk with for the local repository with the > Windows machine leads to executable permission on dependency jars copied to > WEB-INF/lib > normalizing permissions during the copy from local repo to WEB-INF/lib looks > reasonable to solve that environment edge case -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWAR-471) normalize file permissions on dependencies copied to WEB-INF/lib
[ https://issues.apache.org/jira/browse/MWAR-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820395#comment-17820395 ] Herve Boutemy commented on MWAR-471: bq. building on Windows with WLS sharing a disk with for the local repository with the Windows machine I suppose it's the same when you mount a smb disk, that does not track Unix permissions: there is a common permission assigned > normalize file permissions on dependencies copied to WEB-INF/lib > > > Key: MWAR-471 > URL: https://issues.apache.org/jira/browse/MWAR-471 > Project: Maven WAR Plugin > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Herve Boutemy >Priority: Major > > as seen on Jackrabbit releases > https://lists.apache.org/thread/6qxnclwmxggq6j20l8z78yr375vxo508, building on > Windows with WSL sharing a disk with for the local repository with the > Windows machine leads to executable permission on dependency jars copied to > WEB-INF/lib > normalizing permissions during the copy from local repo to WEB-INF/lib looks > reasonable to solve that environment edge case -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWAR-471) normalize file permissions on dependencies copied to WEB-INF/lib
Herve Boutemy created MWAR-471: -- Summary: normalize file permissions on dependencies copied to WEB-INF/lib Key: MWAR-471 URL: https://issues.apache.org/jira/browse/MWAR-471 Project: Maven WAR Plugin Issue Type: Improvement Affects Versions: 3.4.0 Reporter: Herve Boutemy as seen on Jackrabbit releases https://lists.apache.org/thread/6qxnclwmxggq6j20l8z78yr375vxo508, building on Windows with WSL sharing a disk with for the local repository with the Windows machine leads to executable permission on dependency jars copied to WEB-INF/lib normalizing permissions during the copy from local repo to WEB-INF/lib looks reasonable to solve that environment edge case -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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: -- Description: 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" was: 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" > 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 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 prerequsites history
[ https://issues.apache.org/jira/browse/MPLUGIN-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-511: -- Description: 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 was: to help creating documentation needed on plugins when implementing MPLUGIN-400, i.e. fill requirementHistories [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 > create and share tooling to detect plugin prerequsites 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)
[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: -- Description: 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" was: in MPLUGIN-400, we added the feature with a list of versions of the plugin, associated to Maven and JDK prerequisite => 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" > 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 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" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPLUGIN-511) create and share tooling to detect plugin prerequsites history
[ https://issues.apache.org/jira/browse/MPLUGIN-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-511: -- Description: to help creating documentation needed on plugins when implementing MPLUGIN-400, i.e. fill requirementHistories [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 was: to help creating documentation needed on plugins when implementing MPLUGIN-400 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 > create and share tooling to detect plugin prerequsites 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 requirementHistories > [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] [Updated] (MPLUGIN-400) add plugin system requirements history section
[ https://issues.apache.org/jira/browse/MPLUGIN-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPLUGIN-400: -- Description: currently, we generate a system requirement section h3. System Requirements The following specifies the minimum requirements to run this Maven plugin: |Maven|3.0| |JDK|1.7| |Memory|No minimum requirement.| |Disk Space|No minimum requirement.| We also need an history of previous versions to be able to show what was the last version that had another JDK or Maven prerequisite. while at it, I think we can remove memory and disk space that we never use... => solution https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories was: currently, we generate a system requirement section h3. System Requirements The following specifies the minimum requirements to run this Maven plugin: |Maven|3.0| |JDK|1.7| |Memory|No minimum requirement.| |Disk Space|No minimum requirement.| We also need an history of previous versions to be able to show what was the last version that had another JDK or Maven prerequisite. while at it, I think we can remove memory and disk space that we never use... > add plugin system requirements history section > -- > > Key: MPLUGIN-400 > URL: https://issues.apache.org/jira/browse/MPLUGIN-400 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: Plugin Plugin >Reporter: Herve Boutemy >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > > currently, we generate a system requirement section > h3. System Requirements > The following specifies the minimum requirements to run this Maven plugin: > |Maven|3.0| > |JDK|1.7| > |Memory|No minimum requirement.| > |Disk Space|No minimum requirement.| > We also need an history of previous versions to be able to show what was the > last version that had another JDK or Maven prerequisite. > while at it, I think we can remove memory and disk space that we never use... > > => solution > https://maven.apache.org/plugin-tools-archives/plugin-tools-3.7.0/maven-plugin-report-plugin/report-mojo.html#requirementshistories -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-511) create and share tooling to detect plugin prerequsites history
Herve Boutemy created MPLUGIN-511: - Summary: create and share tooling to detect plugin prerequsites 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 Fix For: 3.12.0 to help creating documentation needed on plugins when implementing MPLUGIN-400 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] [Created] (MPLUGIN-510) update plugin system requirements history structure
Herve Boutemy created MPLUGIN-510: - Summary: 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 Plugin Affects Versions: 3.11.0 Reporter: Herve Boutemy 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 => 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" -- This message was sent by Atlassian Jira (v8.20.10#820010)
