[jira] [Updated] (MJLINK-73) Add fork mode
[ https://issues.apache.org/jira/browse/MJLINK-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MJLINK-73: --- Description: Instead of just using Toolchains, we could add a fork=true parameter which will do the same but with the jlink executable from JAVA_HOME. Hint: Due to toolchains, this is actually the default. was:Instead of just using Toolchains, we could add a fork=true parameter which will do the same but with the jlink executable from JAVA_HOME. > Add fork mode > - > > Key: MJLINK-73 > URL: https://issues.apache.org/jira/browse/MJLINK-73 > Project: Maven JLink Plugin > Issue Type: New Feature >Reporter: Benjamin Marwell >Priority: Major > > Instead of just using Toolchains, we could add a fork=true parameter which > will do the same but with the jlink executable from JAVA_HOME. > Hint: Due to toolchains, this is actually the default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJLINK-77) Update description and parameters of --compress to reflect JDK21 changes
Benjamin Marwell created MJLINK-77:
--
Summary: Update description and parameters of --compress to
reflect JDK21 changes
Key: MJLINK-77
URL: https://issues.apache.org/jira/browse/MJLINK-77
Project: Maven JLink Plugin
Issue Type: Task
Reporter: Benjamin Marwell
Assignee: Benjamin Marwell
Starting from Java 21, the allowed parameters for {{compress}} have changed,
and the old ones are suspect to removal:
{code:java}
$ jlink --help
[…]
--compress Compression to use in compressing
resources:
Accepted values are:
zip-[0-9], where zip-0 provides no
compression,
and zip-9 provides the best compression.
Default is zip-6.
Deprecated values to be removed in a
future release:
0: No compression. Equivalent to zip-0.
1: Constant String Sharing
2: Equivalent to zip-6.
{code}
Thus, the current jlink-plugin is incompatible with Java 21:
{code:java}
/**
* Here you can define the compression of the resources being used. The
command line equivalent is:
* -c, --compress=level. The valid values for the level
are: 0, 1, 2.
*/
@Parameter
private Integer compress;
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MCOMPILER-550) Make 'outputDirectory' writable
[
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MCOMPILER-550.
Resolution: Fixed
Fixed in
https://github.com/apache/maven-compiler-plugin/commit/c459d1d2738a78e387e2f67ee86626bc5fc55a7c
> Make 'outputDirectory' writable
> ---
>
> Key: MCOMPILER-550
> URL: https://issues.apache.org/jira/browse/MCOMPILER-550
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.12.0
>
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writable, i.e. not meant to
> be modified.
> However, making it writable has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars)
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only
> be controlled by setting the {{release}} property. That will not only require
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
> Java 24. Here is an example use case:
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For
> example, the SecurityManager is not just deprecated, it is deprecated for
> removal. The moment we know which Java version it is, we can create a MR-Jar
> for e.g. Java 30, even though Java 30 SDKs are not available then (currently
> we have Java 21 GA).
> h2. Proposed solution
> Make variable writable as suggested in Slack.
> PR available locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2204) Convert logging to slf4j to allow MDC to be printed
Benjamin Marwell created SUREFIRE-2204:
--
Summary: Convert logging to slf4j to allow MDC to be printed
Key: SUREFIRE-2204
URL: https://issues.apache.org/jira/browse/SUREFIRE-2204
Project: Maven Surefire
Issue Type: Task
Components: Maven Failsafe Plugin, Maven Surefire Plugin,
surefire-logger-api
Reporter: Benjamin Marwell
Hi,
I would like to use {{mvnd --batch-mode}} in my CI builds (see ticket:
https://github.com/apache/maven-mvnd/issues/789), but the messages printed by
surefire do not use SLF4j (like other plugins) and hence do not print the
module name in front of the actual message.
This makes the output hardly usable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-550) Make 'outputDirectory' writable
[
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MCOMPILER-550:
---
Description:
h2. Description of Improvement
Currently, the property 'outputDirectory' is not writable, i.e. not meant to be
modified.
However, making it writable has at least two major advantages.
h2. Use case one -- variable is already used
Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars) already
make use of rewriting the variable.
h2. Use case two: MR-Jars with different bytecode level.
Another use case is Multi-Release-Jars. Currently, they can officially only be
controlled by setting the {{release}} property. That will not only require a
suitable JDK or Toolchain-JDK, it will also require the bytecode for that
version to be the bytecode of that version.
E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
{{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
However, the JDK does not know of such restrictions.
Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
Java 24. Here is an example use case:
https://github.com/groovy/GMavenPlus/pull/287
Granted, this could also be done differently, but this way it seems a little
more elegant.
The actual advantage is, that some developers can now plan ahead. For example,
the SecurityManager is not just deprecated, it is deprecated for removal. The
moment we know which Java version it is, we can create a MR-Jar for e.g. Java
30, even though Java 30 SDKs are not available then (currently we have Java 21
GA).
h2. Proposed solution
Make variable writable as suggested in Slack.
PR available locally.
was:
h2. Description of Improvement
Currently, the property 'outputDirectory' is not writeable, i.e. not meant to
be modified.
However, making it writeable has at least two major advantages.
h2. Use case one -- variable is already used
Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars) already
make use of rewriting the variable.
h2. Use case two: MR-Jars with different bytecode level.
Another use case is Multi-Release-Jars. Currently, they can officially only be
controlled by setting the {{release}} property. That will not only require a
suitable JDK or Toolchain-JDK, it will also require the bytecode for that
version to be the bytecode of that version.
E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
{{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
However, the JDK does not know of such restrictions.
Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
Java 24. Here is an example use case:
https://github.com/groovy/GMavenPlus/pull/287
Granted, this could also be done differently, but this way it seems a little
more elegant.
The actual advantage is, that some developers can now plan ahead. For example,
the SecurityManager is not just deprecated, it is deprecated for removal. The
moment we know which Java version it is, we can create a MR-Jar for e.g. Java
30, even though Java 30 SDKs are not available then (currently we have Java 21
GA).
h2. Proposed solution
Make variable writeable as suggested in Slack.
PR available locally.
> Make 'outputDirectory' writable
> ---
>
> Key: MCOMPILER-550
> URL: https://issues.apache.org/jira/browse/MCOMPILER-550
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.12.0
>
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writable, i.e. not meant to
> be modified.
> However, making it writable has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars)
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only
> be controlled by setting the {{release}} property. That will not only require
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
> Java 24. Here is an example use case:
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For
> example, the SecurityManager is not
[jira] [Updated] (MCOMPILER-550) Make 'outputDirectory' writable
[
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MCOMPILER-550:
---
Summary: Make 'outputDirectory' writable (was: Make 'outputDirectory'
writeable)
> Make 'outputDirectory' writable
> ---
>
> Key: MCOMPILER-550
> URL: https://issues.apache.org/jira/browse/MCOMPILER-550
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.12.0
>
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writeable, i.e. not meant to
> be modified.
> However, making it writeable has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars)
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only
> be controlled by setting the {{release}} property. That will not only require
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
> Java 24. Here is an example use case:
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For
> example, the SecurityManager is not just deprecated, it is deprecated for
> removal. The moment we know which Java version it is, we can create a MR-Jar
> for e.g. Java 30, even though Java 30 SDKs are not available then (currently
> we have Java 21 GA).
> h2. Proposed solution
> Make variable writeable as suggested in Slack.
> PR available locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-550) Make 'outputDirectory' writeable
[
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MCOMPILER-550:
---
Fix Version/s: 3.12.0
> Make 'outputDirectory' writeable
>
>
> Key: MCOMPILER-550
> URL: https://issues.apache.org/jira/browse/MCOMPILER-550
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.12.0
>
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writeable, i.e. not meant to
> be modified.
> However, making it writeable has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars)
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only
> be controlled by setting the {{release}} property. That will not only require
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
> Java 24. Here is an example use case:
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For
> example, the SecurityManager is not just deprecated, it is deprecated for
> removal. The moment we know which Java version it is, we can create a MR-Jar
> for e.g. Java 30, even though Java 30 SDKs are not available then (currently
> we have Java 21 GA).
> h2. Proposed solution
> Make variable writeable as suggested in Slack.
> PR available locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCOMPILER-550) Make 'outputDirectory' writeable
Benjamin Marwell created MCOMPILER-550:
--
Summary: Make 'outputDirectory' writeable
Key: MCOMPILER-550
URL: https://issues.apache.org/jira/browse/MCOMPILER-550
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: Benjamin Marwell
Assignee: Benjamin Marwell
h2. Description of Improvement
Currently, the property 'outputDirectory' is not writeable, i.e. not meant to
be modified.
However, making it writeable has at least two major advantages.
h2. Use case one -- variable is already used
Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars) already
make use of rewriting the variable.
h2. Use case two: MR-Jars with different bytecode level.
Another use case is Multi-Release-Jars. Currently, they can officially only be
controlled by setting the {{release}} property. That will not only require a
suitable JDK or Toolchain-JDK, it will also require the bytecode for that
version to be the bytecode of that version.
E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
{{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
However, the JDK does not know of such restrictions.
Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
Java 24. Here is an example use case:
https://github.com/groovy/GMavenPlus/pull/287
Granted, this could also be done differently, but this way it seems a little
more elegant.
The actual advantage is, that some developers can now plan ahead. For example,
the SecurityManager is not just deprecated, it is deprecated for removal. The
moment we know which Java version it is, we can create a MR-Jar for e.g. Java
30, even though Java 30 SDKs are not available then (currently we have Java 21
GA).
h2. Proposed solution
Make variable writeable as suggested in Slack.
PR available locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJLINK-68) url in url field instead of description field in pom.xml
[
https://issues.apache.org/jira/browse/MJLINK-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748282#comment-17748282
]
Benjamin Marwell commented on MJLINK-68:
We could just mention the JEPs by name:
{code:xml}
The Maven JLink Plugin is intended to create Modular Run-Time
Images.
Based on JEP-282 and JEP-220
{code}
> url in url field instead of description field in pom.xml
>
>
> Key: MJLINK-68
> URL: https://issues.apache.org/jira/browse/MJLINK-68
> Project: Maven JLink Plugin
> Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> Apache Maven JLink Plugin
> The Maven JLink Plugin is intended to create Modular Run-Time
> Images.
> https://openjdk.java.net/jeps/282,
> https://openjdk.java.net/jeps/220
> 2016
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJLINK-68) url in url field instead of description field in pom.xml
[ https://issues.apache.org/jira/browse/MJLINK-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748274#comment-17748274 ] Benjamin Marwell commented on MJLINK-68: [~elharo] it is not the URL to this project, but to the standard it implements. Which other URL field is suitable in your opinion? > url in url field instead of description field in pom.xml > > > Key: MJLINK-68 > URL: https://issues.apache.org/jira/browse/MJLINK-68 > Project: Maven JLink Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Minor > > Apache Maven JLink Plugin > The Maven JLink Plugin is intended to create Modular Run-Time > Images. > https://openjdk.java.net/jeps/282, > https://openjdk.java.net/jeps/220 > 2016 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJLINK-67) Point issues link in pom to issue list instead of release list
[ https://issues.apache.org/jira/browse/MJLINK-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748272#comment-17748272 ] Benjamin Marwell commented on MJLINK-67: Hi [~elharo], I believe this is fixed in master? Can you check please? > Point issues link in pom to issue list instead of release list > -- > > Key: MJLINK-67 > URL: https://issues.apache.org/jira/browse/MJLINK-67 > Project: Maven JLink Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > https://issues.apache.org/jira/projects/MJLINK/issues/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJLINK-73) Add fork mode
Benjamin Marwell created MJLINK-73: -- Summary: Add fork mode Key: MJLINK-73 URL: https://issues.apache.org/jira/browse/MJLINK-73 Project: Maven JLink Plugin Issue Type: New Feature Reporter: Benjamin Marwell Instead of just using Toolchains, we could add a fork=true parameter which will do the same but with the jlink executable from JAVA_HOME. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJLINK-72) Remove common-lang3
[ https://issues.apache.org/jira/browse/MJLINK-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MJLINK-72. Resolution: Fixed > Remove common-lang3 > --- > > Key: MJLINK-72 > URL: https://issues.apache.org/jira/browse/MJLINK-72 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Fix For: 3.2.0 > > > common-lang3 is only used for very few operations and can be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJLINK-64) Add-options double quoting
[
https://issues.apache.org/jira/browse/MJLINK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MJLINK-64.
Fix Version/s: 3.2.0
Resolution: Fixed
> Add-options double quoting
> --
>
> Key: MJLINK-64
> URL: https://issues.apache.org/jira/browse/MJLINK-64
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Tigran Sargsyan
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.2.0
>
>
> In case of add multiple options via **, they are combined to one
> in runtime. For example :
>
> {code:java}
>
> -Darg1=value1
> -Darg2=value2
>
> {code}
>
>
> In runtime for the following code:
>
> {code:java}
> System.out.println(System.getProperty("arg1"));
> System.out.println(System.getProperty("arg2"));
>
> {code}
> Output is:
>
> {code:java}
> value1 -Darg2=value2
> null
> {code}
>
>
> After I examined the source code, I noticed that in fact, in the final
> command, it turns out something like '*"-Darg1 = value1 -Darg2 = value2"'*
> instead of *"-Darg1 = value1 -Darg2 = value2"*.
> I.e +double quoting.+
> _*My seggesion:*_
> Remove reduntant quoting in file *JlinkMojo(line:657).*
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJLINK-66) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MJLINK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MJLINK-66. Fix Version/s: 3.2.0 Resolution: Fixed Done in https://github.com/apache/maven-jlink-plugin/pull/165 with https://github.com/apache/maven-jlink-plugin/pull/165/commits/a657ce9c9348ba070bb986c2358d316208ec483c > Update parent pom to 39 > --- > > Key: MJLINK-66 > URL: https://issues.apache.org/jira/browse/MJLINK-66 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Benjamin Marwell >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MJLINK-64) Add-options double quoting
[
https://issues.apache.org/jira/browse/MJLINK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell reassigned MJLINK-64:
--
Assignee: Benjamin Marwell
> Add-options double quoting
> --
>
> Key: MJLINK-64
> URL: https://issues.apache.org/jira/browse/MJLINK-64
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Tigran Sargsyan
>Assignee: Benjamin Marwell
>Priority: Major
>
> In case of add multiple options via **, they are combined to one
> in runtime. For example :
>
> {code:java}
>
> -Darg1=value1
> -Darg2=value2
>
> {code}
>
>
> In runtime for the following code:
>
> {code:java}
> System.out.println(System.getProperty("arg1"));
> System.out.println(System.getProperty("arg2"));
>
> {code}
> Output is:
>
> {code:java}
> value1 -Darg2=value2
> null
> {code}
>
>
> After I examined the source code, I noticed that in fact, in the final
> command, it turns out something like '*"-Darg1 = value1 -Darg2 = value2"'*
> instead of *"-Darg1 = value1 -Darg2 = value2"*.
> I.e +double quoting.+
> _*My seggesion:*_
> Remove reduntant quoting in file *JlinkMojo(line:657).*
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MJLINK-66) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MJLINK-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell reassigned MJLINK-66: -- Assignee: Benjamin Marwell > Update parent pom to 39 > --- > > Key: MJLINK-66 > URL: https://issues.apache.org/jira/browse/MJLINK-66 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Benjamin Marwell >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJLINK-72) Remove common-lang3
Benjamin Marwell created MJLINK-72: -- Summary: Remove common-lang3 Key: MJLINK-72 URL: https://issues.apache.org/jira/browse/MJLINK-72 Project: Maven JLink Plugin Issue Type: Dependency upgrade Reporter: Benjamin Marwell Assignee: Benjamin Marwell Fix For: 3.2.0 common-lang3 is only used for very few operations and can be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJLINK-71) Require Maven 3.6.3 as new baseline
[ https://issues.apache.org/jira/browse/MJLINK-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MJLINK-71. Resolution: Fixed > Require Maven 3.6.3 as new baseline > --- > > Key: MJLINK-71 > URL: https://issues.apache.org/jira/browse/MJLINK-71 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJLINK-70) Update m-site-p to 3.12.1
[ https://issues.apache.org/jira/browse/MJLINK-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MJLINK-70. Resolution: Fixed > Update m-site-p to 3.12.1 > - > > Key: MJLINK-70 > URL: https://issues.apache.org/jira/browse/MJLINK-70 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJLINK-71) Require Maven 3.6.3 as new baseline
Benjamin Marwell created MJLINK-71: -- Summary: Require Maven 3.6.3 as new baseline Key: MJLINK-71 URL: https://issues.apache.org/jira/browse/MJLINK-71 Project: Maven JLink Plugin Issue Type: Dependency upgrade Reporter: Benjamin Marwell Assignee: Benjamin Marwell Fix For: 3.2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJLINK-70) Update m-site-p to 3.12.1
Benjamin Marwell created MJLINK-70: -- Summary: Update m-site-p to 3.12.1 Key: MJLINK-70 URL: https://issues.apache.org/jira/browse/MJLINK-70 Project: Maven JLink Plugin Issue Type: Dependency upgrade Reporter: Benjamin Marwell Assignee: Benjamin Marwell Fix For: 3.2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJLINK-69) Update to Java 11
[
https://issues.apache.org/jira/browse/MJLINK-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MJLINK-69.
Resolution: Fixed
> Update to Java 11
> -
>
> Key: MJLINK-69
> URL: https://issues.apache.org/jira/browse/MJLINK-69
> Project: Maven JLink Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Labels: java1.8, java11
> Fix For: 3.2.0
>
>
> Due to the recent changes in the Jenkinsfiles which are now streamlined, this
> plugin is not tested anymore with toolchains. That means, we currently do not
> test with Java 8 running Maven and Java 11 Toolchains.
> However, as this is an improbable and unlikely scenario, we can do the
> following:
> * Require Java 11 for the plugin
> * Move classes from the {{java9}} source folder to the {{java}} source folder
> We *could* move to Java 9 only, but I do not see any benefit from using a
> long-dead non-LTS version as a baseline.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MARCHETYPES-61) Update quickstart to use JUnit 5
[
https://issues.apache.org/jira/browse/MARCHETYPES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746301#comment-17746301
]
Benjamin Marwell commented on MARCHETYPES-61:
-
Hey! Since it has been a year, I suggest we keep the new parameters (system
properties) from the mentioned commit and instead use a different default
version. New Projects are very likely to use junit-jupiter nowadays.
> Update quickstart to use JUnit 5
>
>
> Key: MARCHETYPES-61
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-61
> Project: Maven Archetype Bundles
> Issue Type: Improvement
> Components: Maven Quickstart Archetype
>Affects Versions: 1.3
>Reporter: Dmitry Timofeev
>Priority: Minor
>
> Update quickstart archetype to generate a project using JUnit 5, the next
> version of the most popular testing framework.
> Currently one has to include _at least_ two dependencies on JUnit 5 artefacts
> to enable surefire to run them: junit-jupiter-api and junit-jupiter-engine.
> Possible structure of dependencies:
> {code:java}
>
>
>
> org.junit
> junit-bom
> 5.3.1
> pom
> import
>
>
>
>
>
> org.junit.jupiter
> junit-jupiter-api
> test
>
>
> org.junit.jupiter
> junit-jupiter-engine
> test
>
>
>
> org.junit.jupiter
> junit-jupiter-params
> test
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJLINK-69) Update to Java 11
Benjamin Marwell created MJLINK-69:
--
Summary: Update to Java 11
Key: MJLINK-69
URL: https://issues.apache.org/jira/browse/MJLINK-69
Project: Maven JLink Plugin
Issue Type: Improvement
Reporter: Benjamin Marwell
Assignee: Benjamin Marwell
Fix For: 3.2.0
Due to the recent changes in the Jenkinsfiles which are now streamlined, this
plugin is not tested anymore with toolchains. That means, we currently do not
test with Java 8 running Maven and Java 11 Toolchains.
However, as this is an improbable and unlikely scenario, we can do the
following:
* Require Java 11 for the plugin
* Move classes from the {{java9}} source folder to the {{java}} source folder
We *could* move to Java 9 only, but I do not see any benefit from using a
long-dead non-LTS version as a baseline.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-382) Define local outgoing (bind) address
[
https://issues.apache.org/jira/browse/MRESOLVER-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell reassigned MRESOLVER-382:
--
Assignee: Tamas Cservenak (was: Benjamin Marwell)
Please review (target version, etc.).
> Define local outgoing (bind) address
>
>
> Key: MRESOLVER-382
> URL: https://issues.apache.org/jira/browse/MRESOLVER-382
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Benjamin Marwell
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.10.0
>
>
> Currently, outgoing PUT connections (or download from central for that
> matter) will be resolved over the default route.
> However, this is not always feasible.
> h2. Expected behaviour
> A new property {{aether.connector.http.bind.address}} is defined for outgoing
> requests, so that other routes (other interfaces) can be used.
> h2. Actual behaviour
> Certain systems cannot be reached when a firewall is only opened on a
> non-default interface.
> h2. User Story
> Builds on servers with multiple interfaces:
> * The default route is defined poorly
> * Other interfaces are available and have the requested firewall rules
> * User defines -Daether.connector.http.bind.address=${myotherip} (or local
> address) to make outgoing connections to bind to another interface than the
> default one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-382) Define local outgoing (bind) address
[
https://issues.apache.org/jira/browse/MRESOLVER-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MRESOLVER-382:
---
Fix Version/s: 1.10.0
> Define local outgoing (bind) address
>
>
> Key: MRESOLVER-382
> URL: https://issues.apache.org/jira/browse/MRESOLVER-382
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 1.10.0
>
>
> Currently, outgoing PUT connections (or download from central for that
> matter) will be resolved over the default route.
> However, this is not always feasible.
> h2. Expected behaviour
> A new property {{aether.connector.http.bind.address}} is defined for outgoing
> requests, so that other routes (other interfaces) can be used.
> h2. Actual behaviour
> Certain systems cannot be reached when a firewall is only opened on a
> non-default interface.
> h2. User Story
> Builds on servers with multiple interfaces:
> * The default route is defined poorly
> * Other interfaces are available and have the requested firewall rules
> * User defines -Daether.connector.http.bind.address=${myotherip} (or local
> address) to make outgoing connections to bind to another interface than the
> default one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-382) Define local outgoing (bind) address
[
https://issues.apache.org/jira/browse/MRESOLVER-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell reassigned MRESOLVER-382:
--
Assignee: Benjamin Marwell
> Define local outgoing (bind) address
>
>
> Key: MRESOLVER-382
> URL: https://issues.apache.org/jira/browse/MRESOLVER-382
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>
> Currently, outgoing PUT connections (or download from central for that
> matter) will be resolved over the default route.
> However, this is not always feasible.
> h2. Expected behaviour
> A new property {{aether.connector.http.bind.address}} is defined for outgoing
> requests, so that other routes (other interfaces) can be used.
> h2. Actual behaviour
> Certain systems cannot be reached when a firewall is only opened on a
> non-default interface.
> h2. User Story
> Builds on servers with multiple interfaces:
> * The default route is defined poorly
> * Other interfaces are available and have the requested firewall rules
> * User defines -Daether.connector.http.bind.address=${myotherip} (or local
> address) to make outgoing connections to bind to another interface than the
> default one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-382) Define local outgoing (bind) address
Benjamin Marwell created MRESOLVER-382:
--
Summary: Define local outgoing (bind) address
Key: MRESOLVER-382
URL: https://issues.apache.org/jira/browse/MRESOLVER-382
Project: Maven Resolver
Issue Type: Improvement
Components: Resolver
Reporter: Benjamin Marwell
Currently, outgoing PUT connections (or download from central for that matter)
will be resolved over the default route.
However, this is not always feasible.
h2. Expected behaviour
A new property {{aether.connector.http.bind.address}} is defined for outgoing
requests, so that other routes (other interfaces) can be used.
h2. Actual behaviour
Certain systems cannot be reached when a firewall is only opened on a
non-default interface.
h2. User Story
Builds on servers with multiple interfaces:
* The default route is defined poorly
* Other interfaces are available and have the requested firewall rules
* User defines -Daether.connector.http.bind.address=${myotherip} (or local
address) to make outgoing connections to bind to another interface than the
default one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733939#comment-17733939
]
Benjamin Marwell commented on MSHARED-1032:
---
Ha, I wish I knew which plugin I was trying to modify when I stumbled over
this. Probably the checkstyle-plugin.
Maybe I did not mean "double call", but instead "called on two occurences", but
that is hard to guess from now. If it was from two different entry points, it
should be two different methods (imho). The default can be that one calls
another...
Then there's the exception issue, yes, which can be solved right afterwards.
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731887#comment-17731887
]
Benjamin Marwell commented on MBUILDCACHE-61:
-
Yes. Maybe I should have slapped 'needs documentation' on it.
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Updated] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MBUILDCACHE-61:
Labels: documentation (was: )
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: documentation
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-core-3.9.2.jar
>
[jira] [Updated] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MBUILDCACHE-61:
Summary: XXMM hash algorithm does not work on Java 17 (was: XX hash
algorithm does not work on Java 17)
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/webappsrv/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/de.fi.my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Updated] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MBUILDCACHE-61:
Description:
h2. Actual behaviour
When trying to use XXMM, I get this error:
{code:java}
$ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
-Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
[INFO] Using XXMM hash algorithm for cache
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[...]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.386 s
[INFO] Finished at: 2023-06-12T11:58:13+02:00
[INFO]
[INFO] Saving cache report on build completion
[INFO] Saved to remote cache
dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
---
constituent[0]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
constituent[1]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
constituent[2]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
constituent[3]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
constituent[4]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
constituent[5]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
constituent[6]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
constituent[7]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
constituent[8]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
constituent[9]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
constituent[10]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
constituent[11]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
constituent[12]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
constituent[13]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
constituent[14]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
constituent[15]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
constituent[16]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
constituent[17]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
constituent[18]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
constituent[19]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
constituent[20]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
constituent[21]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
constituent[22]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
constituent[23]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-core-3.9.2.jar
constituent[24]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/failureaccess-1.0.1.jar
constituent[25]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-builder-support-3.9.2.jar
constituent[26]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/jcl-over-slf4j-1.7.36.jar
constituent[27]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-util-1.9.10.jar
constituent[28]:
[jira] [Updated] (MBUILDCACHE-61) XX hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MBUILDCACHE-61:
Description:
h2. Actual behaviour
When trying to use XXMM, I get this error:
{code:java}
$ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
-Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
from $HOME/Projects/git/webappsrv/my-app/.mvn/maven-build-cache-config.xml
[INFO] Using XXMM hash algorithm for cache
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[...]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.386 s
[INFO] Finished at: 2023-06-12T11:58:13+02:00
[INFO]
[INFO] Saving cache report on build completion
[INFO] Saved to remote cache
dav:http://my-server:8049/build-cache/my-app//v1/de.fi.my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
---
constituent[0]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
constituent[1]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
constituent[2]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
constituent[3]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
constituent[4]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
constituent[5]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
constituent[6]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
constituent[7]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
constituent[8]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
constituent[9]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
constituent[10]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
constituent[11]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
constituent[12]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
constituent[13]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
constituent[14]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
constituent[15]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
constituent[16]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
constituent[17]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
constituent[18]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
constituent[19]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
constituent[20]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
constituent[21]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
constituent[22]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
constituent[23]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-core-3.9.2.jar
constituent[24]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/failureaccess-1.0.1.jar
constituent[25]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-builder-support-3.9.2.jar
constituent[26]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/jcl-over-slf4j-1.7.36.jar
constituent[27]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-util-1.9.10.jar
constituent[28]:
[jira] [Updated] (MBUILDCACHE-61) XX hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MBUILDCACHE-61:
Summary: XX hash algorithm does not work on Java 17 (was: XX(MM) hash
algorithm does not work on Java 17)
> XX hash algorithm does not work on Java 17
> --
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/webappsrv/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/de.fi.my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Created] (MBUILDCACHE-61) XX(MM) hash algorithm does not work on Java 17
Benjamin Marwell created MBUILDCACHE-61:
---
Summary: XX(MM) hash algorithm does not work on Java 17
Key: MBUILDCACHE-61
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
Project: Maven Build Cache Extension
Issue Type: Bug
Components: remote build cache
Reporter: Benjamin Marwell
h2. Actual behaviour
When trying to use XXMM, I get this error:
{code:java}
$ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
-Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
from $HOME/Projects/git/webappsrv/my-app/.mvn/maven-build-cache-config.xml
[INFO] Using XXMM hash algorithm for cache
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[...]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.386 s
[INFO] Finished at: 2023-06-12T11:58:13+02:00
[INFO]
[INFO] Saving cache report on build completion
[INFO] Saved to remote cache
dav:http://my-server:8049/build-cache/my-app//v1/de.fi.my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
---
constituent[0]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
constituent[1]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
constituent[2]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
constituent[3]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
constituent[4]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
constituent[5]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
constituent[6]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
constituent[7]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
constituent[8]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
constituent[9]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
constituent[10]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
constituent[11]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
constituent[12]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
constituent[13]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
constituent[14]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
constituent[15]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
constituent[16]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
constituent[17]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
constituent[18]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
constituent[19]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
constituent[20]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
constituent[21]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
constituent[22]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
constituent[23]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-core-3.9.2.jar
constituent[24]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/failureaccess-1.0.1.jar
constituent[25]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-builder-support-3.9.2.jar
constituent[26]:
file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/jcl-over-slf4j-1.7.36.jar
constituent[27]:
[jira] [Created] (MNG-7808) Remove warnings of undefined plugin versions
Benjamin Marwell created MNG-7808: - Summary: Remove warnings of undefined plugin versions Key: MNG-7808 URL: https://issues.apache.org/jira/browse/MNG-7808 Project: Maven Issue Type: Improvement Components: Core, Logging Reporter: Benjamin Marwell h2. Actual behaviour Maven issues warnings about undefined plugin versions when not needed h2. Expected behaviour Maven should not issue warnings about undefined plugin versions early in a project build. h2. Rationale The release plugin will be modified to reject releases of projects which are not defining all plugin versions: [MRELEASE-1130] Reject release of project containing undefined plugin versions - ASF JIRA (apache.org) Once that is done, we can remove the warnings from core: 1.) There should be as few as possible warnings OOTB on new maven projects 2.) It is not really important for local builds to define plugin versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRELEASE-1130) Reject undefined plugin versions
Benjamin Marwell created MRELEASE-1130: -- Summary: Reject undefined plugin versions Key: MRELEASE-1130 URL: https://issues.apache.org/jira/browse/MRELEASE-1130 Project: Maven Release Plugin Issue Type: Improvement Components: prepare, prepare-with-pom Reporter: Benjamin Marwell As discussed in slack, the m-release-p should reject releases where at least one plugin version was not set. The warning didn't cut it and can be removed once this is done, because it does not really matter for local builds – unless a dev uses an old maven version which leads to a bug, but then there is Maven Wrapper to rule that out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRELEASE-1130) Reject release of project containing undefined plugin versions
[ https://issues.apache.org/jira/browse/MRELEASE-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MRELEASE-1130: --- Summary: Reject release of project containing undefined plugin versions (was: Reject undefined plugin versions) > Reject release of project containing undefined plugin versions > -- > > Key: MRELEASE-1130 > URL: https://issues.apache.org/jira/browse/MRELEASE-1130 > Project: Maven Release Plugin > Issue Type: Improvement > Components: prepare, prepare-with-pom >Reporter: Benjamin Marwell >Priority: Major > > As discussed in slack, the m-release-p should reject releases where at least > one plugin version was not set. > The warning didn't cut it and can be removed once this is done, because it > does not really matter for local builds – unless a dev uses an old maven > version which leads to a bug, but then there is Maven Wrapper to rule that > out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-474) Improve descriptor-docs for requiredJavaVersion
Benjamin Marwell created MPLUGIN-474: Summary: Improve descriptor-docs for requiredJavaVersion Key: MPLUGIN-474 URL: https://issues.apache.org/jira/browse/MPLUGIN-474 Project: Maven Plugin Tools Issue Type: Improvement Components: Plugin Plugin Reporter: Benjamin Marwell The documentation for the parameter "requiredJavaVersion" has examples which do not suit the content of the paramter. Good examples should include real java versions, not Maven versions. They should be sth like 1.8 or 8, 9, ,etc. [https://maven.apache.org/plugin-tools/maven-plugin-plugin/descriptor-mojo.html#requiredJavaVersion] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MWRAPPER-104) Add prettier config for shell scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell reassigned MWRAPPER-104: - Assignee: Slawomir Jaranowski (was: Benjamin Marwell) > Add prettier config for shell scripts > - > > Key: MWRAPPER-104 > URL: https://issues.apache.org/jira/browse/MWRAPPER-104 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Reporter: Benjamin Marwell >Assignee: Slawomir Jaranowski >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-104) Add prettier config for shell scripts
Benjamin Marwell created MWRAPPER-104: - Summary: Add prettier config for shell scripts Key: MWRAPPER-104 URL: https://issues.apache.org/jira/browse/MWRAPPER-104 Project: Maven Wrapper Issue Type: Improvement Components: Maven Wrapper Scripts Reporter: Benjamin Marwell Assignee: Benjamin Marwell -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-88) mvnw is not POSIX compatible
[ https://issues.apache.org/jira/browse/MWRAPPER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MWRAPPER-88: - Fix Version/s: 3.2.0 > mvnw is not POSIX compatible > > > Key: MWRAPPER-88 > URL: https://issues.apache.org/jira/browse/MWRAPPER-88 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.1 >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: posix > Fix For: 3.2.0 > > > * POSIX scripts should not use bash-specific features > * Fix suggestions from shellcheck > ([https://github.com/apache/maven-wrapper/pull/74]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MWRAPPER-88) mvnw is not POSIX compatible
[ https://issues.apache.org/jira/browse/MWRAPPER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MWRAPPER-88. -- Resolution: Fixed fixed with https://github.com/apache/maven-wrapper/commit/7840c9036eb6e082f53ff6c18c87c82e21819e02 > mvnw is not POSIX compatible > > > Key: MWRAPPER-88 > URL: https://issues.apache.org/jira/browse/MWRAPPER-88 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.1 >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: posix > > * POSIX scripts should not use bash-specific features > * Fix suggestions from shellcheck > ([https://github.com/apache/maven-wrapper/pull/74]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-90) Use arrays to preserve potential whitespace in arguments
Benjamin Marwell created MWRAPPER-90:
Summary: Use arrays to preserve potential whitespace in arguments
Key: MWRAPPER-90
URL: https://issues.apache.org/jira/browse/MWRAPPER-90
Project: Maven Wrapper
Issue Type: Improvement
Components: Maven Wrapper Scripts
Reporter: Benjamin Marwell
The bash scripts call mvn using:
{code:java}
# shellcheck disable=SC2086 # safe args
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@"{code}
However, this might mangle parameters containing spaces into multiple
parameters. It would be only safe when using arrays and use quotes, e.g.
{{{}"${MAVEN_OPTS[@]}"{}}}. Same for the others. This would also allow us to
disable the shellcheck check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-89) Update maven-parent to v39
[ https://issues.apache.org/jira/browse/MWRAPPER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656274#comment-17656274 ] Benjamin Marwell commented on MWRAPPER-89: -- fixed with https://github.com/apache/maven-wrapper/commit/8a1ded6cc4de5b2c9e238efe84ae122fdd8db050 > Update maven-parent to v39 > -- > > Key: MWRAPPER-89 > URL: https://issues.apache.org/jira/browse/MWRAPPER-89 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJLINK-39) Add support for choosing vm
[
https://issues.apache.org/jira/browse/MJLINK-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MJLINK-39.
Assignee: Benjamin Marwell
Resolution: Won't Do
> Add support for choosing vm
> ---
>
> Key: MJLINK-39
> URL: https://issues.apache.org/jira/browse/MJLINK-39
> Project: Maven JLink Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0-alpha-1, 3.0.0, 3.1.0
>Reporter: Nicolai Ehemann
>Assignee: Benjamin Marwell
>Priority: Minor
>
> With jlink it is possible to select which vm will be bundled:
> {code:java}
> --vm={client|server|minimal|all}
> Selects the HotSpot VM in the output image. Default is all{code}
> This should also be possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJLINK-39) Add support for choosing vm
[
https://issues.apache.org/jira/browse/MJLINK-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MJLINK-39:
---
Priority: Minor (was: Blocker)
> Add support for choosing vm
> ---
>
> Key: MJLINK-39
> URL: https://issues.apache.org/jira/browse/MJLINK-39
> Project: Maven JLink Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0-alpha-1, 3.0.0, 3.1.0
>Reporter: Nicolai Ehemann
>Priority: Minor
>
> With jlink it is possible to select which vm will be bundled:
> {code:java}
> --vm={client|server|minimal|all}
> Selects the HotSpot VM in the output image. Default is all{code}
> This should also be possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJLINK-39) Add support for choosing vm
[
https://issues.apache.org/jira/browse/MJLINK-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MJLINK-39:
---
Priority: Blocker (was: Major)
> Add support for choosing vm
> ---
>
> Key: MJLINK-39
> URL: https://issues.apache.org/jira/browse/MJLINK-39
> Project: Maven JLink Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0-alpha-1, 3.0.0, 3.1.0
>Reporter: Nicolai Ehemann
>Priority: Blocker
>
> With jlink it is possible to select which vm will be bundled:
> {code:java}
> --vm={client|server|minimal|all}
> Selects the HotSpot VM in the output image. Default is all{code}
> This should also be possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJLINK-65) Filter out automatic modules
[ https://issues.apache.org/jira/browse/MJLINK-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655825#comment-17655825 ] Benjamin Marwell commented on MJLINK-65: Hi [~h...@apteryx.fr] - sorry for only replying now. * Can you give us more details what you mean by "filtering out"? Whhaht is the expected jlink(.exe) call? * Could other projects break? * Did you consider or try to use optional/provided dependencies? > Filter out automatic modules > > > Key: MJLINK-65 > URL: https://issues.apache.org/jira/browse/MJLINK-65 > Project: Maven JLink Plugin > Issue Type: New Feature >Affects Versions: 3.1.0 >Reporter: Hervé Guillemet >Priority: Major > > The plugin currently adds to the jlink image all modules found in the Maven > dependencies. If such modules are automatic modules, jlink will fail. > This prevents, for instance, to build the image of an application using > JavaFX jars since JavaFX uses an empty automatic module (e.g. in > javafx-controls-17.0.2.jar) as a dependency bridge between applications and > platform specific jars (e.g. javafx-controls-17.0.2-linux.jar). > Could you consider filtering out automatic modules ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJLINK-39) Add support for choosing vm
[
https://issues.apache.org/jira/browse/MJLINK-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655824#comment-17655824
]
Benjamin Marwell commented on MJLINK-39:
[~McNetic] are you still on x86_32 and do you still need this option?
> Add support for choosing vm
> ---
>
> Key: MJLINK-39
> URL: https://issues.apache.org/jira/browse/MJLINK-39
> Project: Maven JLink Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0-alpha-1, 3.0.0, 3.1.0
>Reporter: Nicolai Ehemann
>Priority: Major
>
> With jlink it is possible to select which vm will be bundled:
> {code:java}
> --vm={client|server|minimal|all}
> Selects the HotSpot VM in the output image. Default is all{code}
> This should also be possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-89) Update maven-parent to v39
[ https://issues.apache.org/jira/browse/MWRAPPER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MWRAPPER-89: - Fix Version/s: 3.2.0 > Update maven-parent to v39 > -- > > Key: MWRAPPER-89 > URL: https://issues.apache.org/jira/browse/MWRAPPER-89 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MWRAPPER-89) Update maven-parent to v39
[ https://issues.apache.org/jira/browse/MWRAPPER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MWRAPPER-89. -- Resolution: Fixed > Update maven-parent to v39 > -- > > Key: MWRAPPER-89 > URL: https://issues.apache.org/jira/browse/MWRAPPER-89 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-88) mvnw is not POSIX compatible
[ https://issues.apache.org/jira/browse/MWRAPPER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MWRAPPER-88: - Description: * POSIX scripts should not use bash-specific features * Fix suggestions from shellcheck ([https://github.com/apache/maven-wrapper/pull/74]) was: * POSIX scripts should not use bash-specific features * the location of sh is NOT /bin/sh. Instead use /usr/bin/env sh. * Fix suggestions from shellcheck (https://github.com/apache/maven-wrapper/pull/74) > mvnw is not POSIX compatible > > > Key: MWRAPPER-88 > URL: https://issues.apache.org/jira/browse/MWRAPPER-88 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.1 >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: posix > > * POSIX scripts should not use bash-specific features > * Fix suggestions from shellcheck > ([https://github.com/apache/maven-wrapper/pull/74]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-89) Update maven-parent to v39
Benjamin Marwell created MWRAPPER-89: Summary: Update maven-parent to v39 Key: MWRAPPER-89 URL: https://issues.apache.org/jira/browse/MWRAPPER-89 Project: Maven Wrapper Issue Type: Dependency upgrade Reporter: Benjamin Marwell Assignee: Benjamin Marwell -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-88) mvnw is not POSIX compatible
Benjamin Marwell created MWRAPPER-88: Summary: mvnw is not POSIX compatible Key: MWRAPPER-88 URL: https://issues.apache.org/jira/browse/MWRAPPER-88 Project: Maven Wrapper Issue Type: Bug Components: Maven Wrapper Scripts Affects Versions: 3.1.1 Reporter: Benjamin Marwell Assignee: Benjamin Marwell * POSIX scripts should not use bash-specific features * the location of sh is NOT /bin/sh. Instead use /usr/bin/env sh. * Fix suggestions from shellcheck (https://github.com/apache/maven-wrapper/pull/74) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-77) wrapper:wrapper does not update scripts
[
https://issues.apache.org/jira/browse/MWRAPPER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MWRAPPER-77:
-
Fix Version/s: 3.2.0
> wrapper:wrapper does not update scripts
> ---
>
> Key: MWRAPPER-77
> URL: https://issues.apache.org/jira/browse/MWRAPPER-77
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Affects Versions: 3.1.1
>Reporter: Tamas Cservenak
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.2.0
>
>
> On my ancient project seems that scripts (mvnw and mvnw.cmd) were not updated
> after I ran {{wrapper:wrapper}} while the rest was okay.
> To test my assumption, moved them to mvnw.old and mvnw.cmd.old and re-run
> {{{}wrapper:wrapper{}}}. This time the scripts were written out just fine.
> But, they were totally different. This also means that scrpts, once written
> out, will never we updated?
> End result I had:
> {noformat}
> -rwxr-xr-x. 1 cstamas cstamas 9781 máj 8 09.15 mvnw
> -rw-r--r--. 1 cstamas cstamas 6889 máj 8 09.15 mvnw.cmd
> -rw-r--r--. 1 cstamas cstamas 6607 szept 1 15.55 mvnw.cmd.old
> -rwxr-xr-x. 1 cstamas cstamas 10069 szept 1 15.55 mvnw.old {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MWRAPPER-77) wrapper:wrapper does not update scripts
[
https://issues.apache.org/jira/browse/MWRAPPER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MWRAPPER-77.
--
Assignee: Benjamin Marwell
Resolution: Fixed
Updated plexus-archiver
> wrapper:wrapper does not update scripts
> ---
>
> Key: MWRAPPER-77
> URL: https://issues.apache.org/jira/browse/MWRAPPER-77
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Affects Versions: 3.1.1
>Reporter: Tamas Cservenak
>Assignee: Benjamin Marwell
>Priority: Major
>
> On my ancient project seems that scripts (mvnw and mvnw.cmd) were not updated
> after I ran {{wrapper:wrapper}} while the rest was okay.
> To test my assumption, moved them to mvnw.old and mvnw.cmd.old and re-run
> {{{}wrapper:wrapper{}}}. This time the scripts were written out just fine.
> But, they were totally different. This also means that scrpts, once written
> out, will never we updated?
> End result I had:
> {noformat}
> -rwxr-xr-x. 1 cstamas cstamas 9781 máj 8 09.15 mvnw
> -rw-r--r--. 1 cstamas cstamas 6889 máj 8 09.15 mvnw.cmd
> -rw-r--r--. 1 cstamas cstamas 6607 szept 1 15.55 mvnw.cmd.old
> -rwxr-xr-x. 1 cstamas cstamas 10069 szept 1 15.55 mvnw.old {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-77) wrapper:wrapper does not update scripts
[
https://issues.apache.org/jira/browse/MWRAPPER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648222#comment-17648222
]
Benjamin Marwell commented on MWRAPPER-77:
--
Good point indeed! However, silently *not* updating is no option, too. ;)
> wrapper:wrapper does not update scripts
> ---
>
> Key: MWRAPPER-77
> URL: https://issues.apache.org/jira/browse/MWRAPPER-77
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Affects Versions: 3.1.1
>Reporter: Tamas Cservenak
>Priority: Major
>
> On my ancient project seems that scripts (mvnw and mvnw.cmd) were not updated
> after I ran {{wrapper:wrapper}} while the rest was okay.
> To test my assumption, moved them to mvnw.old and mvnw.cmd.old and re-run
> {{{}wrapper:wrapper{}}}. This time the scripts were written out just fine.
> But, they were totally different. This also means that scrpts, once written
> out, will never we updated?
> End result I had:
> {noformat}
> -rwxr-xr-x. 1 cstamas cstamas 9781 máj 8 09.15 mvnw
> -rw-r--r--. 1 cstamas cstamas 6889 máj 8 09.15 mvnw.cmd
> -rw-r--r--. 1 cstamas cstamas 6607 szept 1 15.55 mvnw.cmd.old
> -rwxr-xr-x. 1 cstamas cstamas 10069 szept 1 15.55 mvnw.old {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MWRAPPER-33) Use java 8 in maven-wrapper
[
https://issues.apache.org/jira/browse/MWRAPPER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell reassigned MWRAPPER-33:
Assignee: Benjamin Marwell
> Use java 8 in maven-wrapper
> ---
>
> Key: MWRAPPER-33
> URL: https://issues.apache.org/jira/browse/MWRAPPER-33
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Jar
>Affects Versions: 3.1.0
>Reporter: Slawomir Jaranowski
>Assignee: Benjamin Marwell
>Priority: Major
> Labels: up-for-grabs
>
> Currently {{maven-wrapper}} use java {*}5{*}.
> It blocks build project on java > 8.
> {{maven-wrapper-plugin}} require java 8, so we can use {{maven-wrapper}} with
> java 5 but we can't install it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-85) Docs do not mention distributionType for MavenWrapperDownloader.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MWRAPPER-85: - Summary: Docs do not mention distributionType for MavenWrapperDownloader.jar (was: wrapper:wrapper fails to install MavenWrapperDownloader.java) > Docs do not mention distributionType for MavenWrapperDownloader.jar > --- > > Key: MWRAPPER-85 > URL: https://issues.apache.org/jira/browse/MWRAPPER-85 > Project: Maven Wrapper > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: Documentation > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-85) wrapper:wrapper fails to install MavenWrapperDownloader.java
[ https://issues.apache.org/jira/browse/MWRAPPER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MWRAPPER-85: - Summary: wrapper:wrapper fails to install MavenWrapperDownloader.java (was: docs still mention MavenWrapperDownloader.java) > wrapper:wrapper fails to install MavenWrapperDownloader.java > > > Key: MWRAPPER-85 > URL: https://issues.apache.org/jira/browse/MWRAPPER-85 > Project: Maven Wrapper > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: Documentation > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-85) docs still mention MavenWrapperDownloader.java
Benjamin Marwell created MWRAPPER-85: Summary: docs still mention MavenWrapperDownloader.java Key: MWRAPPER-85 URL: https://issues.apache.org/jira/browse/MWRAPPER-85 Project: Maven Wrapper Issue Type: Bug Affects Versions: 3.1.1 Reporter: Benjamin Marwell Assignee: Benjamin Marwell -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MNGSITE-503) add .well-known/security.txt
[ https://issues.apache.org/jira/browse/MNGSITE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MNGSITE-503. -- Resolution: Fixed > add .well-known/security.txt > > > Key: MNGSITE-503 > URL: https://issues.apache.org/jira/browse/MNGSITE-503 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: security > > As per consensus on the mailing list (+1 from [~rmannibucau] and me), we > should add a file `.well-known/security.txt`. > I will prepare a PR. > References: > * [.well-known/security.txt at maven.apache.org > (mail-archive.com)|https://www.mail-archive.com/dev@maven.apache.org/msg128366.html] > * [.well-known/security.txt at maven.apache.org-Apache Mail > Archives|https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy] > * [RFC 9116|https://datatracker.ietf.org/doc/html/rfc9116] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNGSITE-503) add .well-known/security.txt
[ https://issues.apache.org/jira/browse/MNGSITE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MNGSITE-503: - Description: As per consensus on the mailing list (+1 from [~rmannibucau] and me), we should add a file `.well-known/security.txt`. I will prepare a PR. References: * [.well-known/security.txt at maven.apache.org (mail-archive.com)|https://www.mail-archive.com/dev@maven.apache.org/msg128366.html] * [.well-known/security.txt at maven.apache.org-Apache Mail Archives|https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy] was: As per consensus on the mailing list (+1 from [~rmannibucau] and me), we should add a file `.well-known/security.txt`. I will prepare a PR. > add .well-known/security.txt > > > Key: MNGSITE-503 > URL: https://issues.apache.org/jira/browse/MNGSITE-503 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: security > > As per consensus on the mailing list (+1 from [~rmannibucau] and me), we > should add a file `.well-known/security.txt`. > I will prepare a PR. > References: > * [.well-known/security.txt at maven.apache.org > (mail-archive.com)|https://www.mail-archive.com/dev@maven.apache.org/msg128366.html] > * [.well-known/security.txt at maven.apache.org-Apache Mail > Archives|https://lists.apache.org/thread/tvfg1lx9nd72c9t4t4s3zlx6l0tpnmwy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNGSITE-503) add .well-known/security.txt
Benjamin Marwell created MNGSITE-503: Summary: add .well-known/security.txt Key: MNGSITE-503 URL: https://issues.apache.org/jira/browse/MNGSITE-503 Project: Maven Project Web Site Issue Type: Improvement Reporter: Benjamin Marwell Assignee: Benjamin Marwell As per consensus on the mailing list (+1 from [~rmannibucau] and me), we should add a file `.well-known/security.txt`. I will prepare a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJDEPS-28) TravisCI builds need to be removed
[ https://issues.apache.org/jira/browse/MJDEPS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MJDEPS-28. Resolution: Fixed > TravisCI builds need to be removed > -- > > Key: MJDEPS-28 > URL: https://issues.apache.org/jira/browse/MJDEPS-28 > Project: Maven JDeps Plugin > Issue Type: Task >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > > As to ASF Infra, TravisCI builds need to be removed from Apache projects by > the end of the year. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJDEPS-28) TravisCI builds need to be removed
[ https://issues.apache.org/jira/browse/MJDEPS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MJDEPS-28: --- Fix Version/s: 3.1.3 > TravisCI builds need to be removed > -- > > Key: MJDEPS-28 > URL: https://issues.apache.org/jira/browse/MJDEPS-28 > Project: Maven JDeps Plugin > Issue Type: Task >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Fix For: 3.1.3 > > > As to ASF Infra, TravisCI builds need to be removed from Apache projects by > the end of the year. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJDEPS-28) TravisCI builds need to be removed
Benjamin Marwell created MJDEPS-28: -- Summary: TravisCI builds need to be removed Key: MJDEPS-28 URL: https://issues.apache.org/jira/browse/MJDEPS-28 Project: Maven JDeps Plugin Issue Type: Task Reporter: Benjamin Marwell Assignee: Benjamin Marwell As to ASF Infra, TravisCI builds need to be removed from Apache projects by the end of the year. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-426) Description annotation for Mojo and Parameters
[
https://issues.apache.org/jira/browse/MPLUGIN-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618898#comment-17618898
]
Benjamin Marwell commented on MPLUGIN-426:
--
There is no kotlin extractor as to my knowledge. Also, I tried to write one.
But it is extremely complicated and I have to copy methods over and over,
because all methods here are private.
> Description annotation for Mojo and Parameters
> --
>
> Key: MPLUGIN-426
> URL: https://issues.apache.org/jira/browse/MPLUGIN-426
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: maven-plugin-annotations, Plugin Plugin
>Affects Versions: 3.4, 3.5.2, 3.6.4
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hey all!
> h2. Overview
> This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247
> which was closed as won't fix.
> I tried to implement a kotlin parser, but it is really hard to do so, because
> you cannot reuse any of the Methods from JavaAnnotationsParser.
> That said, someone used messy reflections for this:
> [https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67]
> Trying this without reflection will lead you to iterate over files again and
> again (here's a barebone):
> [https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87]
> Tamas' request was to have one extractor per JVM language in a separate
> project. But due to his current API changes, this would be a lot of work to
> do!
> [https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc]
> especially you'd have to mantain multiple versions (<3.7, >= 3.7).
> h2. Downsides of custom extractors
> # Setting up as a user is complicated, see this example:
> {code:java}
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
>
> com.carrotgarden.maven
>
> maven-plugin-tools-annotations
> [1,2)
>
>
>
> bintray
>
>
> java-annotations-extra
>
>
> {code}
> # More dependencies to update!
> # You need two versions: One for plugin-tools <3.7 and one for plugin tools
> >=3.7 due to API incompatiblity (new interface methods without defaults).
> h2. Alternative: Provide @Description annotation
> That said, just adding a description mojo with fields "description", "since",
> "deprecated" would be the easiest way to solve this. It is easily backwards
> compatible (just use javadoc if no annotation is present) and it is similar
> to what OpenAPI annotations do - they do not parse javadoc either. Besides,
> Javadoc can have a different level of detail comparing to the Mojo
> Descrption. So a separation might be feasible after all!
>
> This enables plugins written in scala, kotlin and groovy (and any fancy
> language for the JVM in the future) to be written with full documentation,
> without requiring maven-plugin-plugin to have per-language extension and
> source code parser dependency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-426) Description annotation for Mojo and Parameters
[
https://issues.apache.org/jira/browse/MPLUGIN-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618894#comment-17618894
]
Benjamin Marwell commented on MPLUGIN-426:
--
Konrad, the problem is: kotlin does not have Javadoc. The description cannot be
set in Mojos vias kdoc (their javadoc pendant).
Reason is qdox only reads javadoc.
The problem we are trying to solve: we want to write pure kotlin plugins
(Mojos). Currently, there is no way to set the description.
> Description annotation for Mojo and Parameters
> --
>
> Key: MPLUGIN-426
> URL: https://issues.apache.org/jira/browse/MPLUGIN-426
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: maven-plugin-annotations, Plugin Plugin
>Affects Versions: 3.4, 3.5.2, 3.6.4
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hey all!
> h2. Overview
> This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247
> which was closed as won't fix.
> I tried to implement a kotlin parser, but it is really hard to do so, because
> you cannot reuse any of the Methods from JavaAnnotationsParser.
> That said, someone used messy reflections for this:
> [https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67]
> Trying this without reflection will lead you to iterate over files again and
> again (here's a barebone):
> [https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87]
> Tamas' request was to have one extractor per JVM language in a separate
> project. But due to his current API changes, this would be a lot of work to
> do!
> [https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc]
> especially you'd have to mantain multiple versions (<3.7, >= 3.7).
> h2. Downsides of custom extractors
> # Setting up as a user is complicated, see this example:
> {code:java}
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
>
> com.carrotgarden.maven
>
> maven-plugin-tools-annotations
> [1,2)
>
>
>
> bintray
>
>
> java-annotations-extra
>
>
> {code}
> # More dependencies to update!
> # You need two versions: One for plugin-tools <3.7 and one for plugin tools
> >=3.7 due to API incompatiblity (new interface methods without defaults).
> h2. Alternative: Provide @Description annotation
> That said, just adding a description mojo with fields "description", "since",
> "deprecated" would be the easiest way to solve this. It is easily backwards
> compatible (just use javadoc if no annotation is present) and it is similar
> to what OpenAPI annotations do - they do not parse javadoc either. Besides,
> Javadoc can have a different level of detail comparing to the Mojo
> Descrption. So a separation might be feasible after all!
>
> This enables plugins written in scala, kotlin and groovy (and any fancy
> language for the JVM in the future) to be written with full documentation,
> without requiring maven-plugin-plugin to have per-language extension and
> source code parser dependency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-426) Description annotation for Mojo and Parameters
[
https://issues.apache.org/jira/browse/MPLUGIN-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618149#comment-17618149
]
Benjamin Marwell commented on MPLUGIN-426:
--
I don't think JFR classes are in the Java SDK. That means it would not compile
with other tck compatible JDKs like Eclipse OpenJ9 (ie IBM Semeru runtimes). I
suggest creating our own annotation.
That said, while this is a compatible change, using the annotation also has
advantages for Java Mojod: the Javadoc can include information normally not
provided to the site, like implementation hints. That means using an annotation
enables distinction between JavaDoc and Mojo description, which might be useful
for some devs.
We should also support basic html tags, like Javadoc does.
> Description annotation for Mojo and Parameters
> --
>
> Key: MPLUGIN-426
> URL: https://issues.apache.org/jira/browse/MPLUGIN-426
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: maven-plugin-annotations, Plugin Plugin
>Affects Versions: 3.4, 3.5.2, 3.6.4
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hey all!
> h2. Overview
> This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247
> which was closed as won't fix.
> I tried to implement a kotlin parser, but it is really hard to do so, because
> you cannot reuse any of the Methods from JavaAnnotationsParser.
> That said, someone used messy reflections for this:
> [https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67]
> Trying this without reflection will lead you to iterate over files again and
> again (here's a barebone):
> [https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87]
> Tamas' request was to have one extractor per JVM language in a separate
> project. But due to his current API changes, this would be a lot of work to
> do!
> [https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc]
> especially you'd have to mantain multiple versions (<3.7, >= 3.7).
> h2. Downsides of custom extractors
> # Setting up as a user is complicated, see this example:
> {code:java}
>
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
>
>
> com.carrotgarden.maven
>
> maven-plugin-tools-annotations
> [1,2)
>
>
>
> bintray
>
>
> java-annotations-extra
>
>
> {code}
> # More dependencies to update!
> # You need two versions: One for plugin-tools <3.7 and one for plugin tools
> >=3.7 due to API incompatiblity (new interface methods without defaults).
> h2. Alternative: Provide @Description annotation
> That said, just adding a description mojo with fields "description", "since",
> "deprecated" would be the easiest way to solve this. It is easily backwards
> compatible (just use javadoc if no annotation is present) and it is similar
> to what OpenAPI annotations do - they do not parse javadoc either. Besides,
> Javadoc can have a different level of detail comparing to the Mojo
> Descrption. So a separation might be feasible after all!
>
> This enables plugins written in scala, kotlin and groovy (and any fancy
> language for the JVM in the future) to be written with full documentation,
> without requiring maven-plugin-plugin to have per-language extension and
> source code parser dependency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPLUGIN-426) MojoDescription annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MPLUGIN-426:
-
Description:
Hey all!
h2. Overview
This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247
which was closed as won't fix.
I tried to implement a kotlin parser, but it is really hard to do so, because
you cannot reuse any of the Methods from JavaAnnotationsParser.
That said, someone used messy reflections for this:
[https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67]
Trying this without reflection will lead you to iterate over files again and
again (here's a barebone):
[https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87]
Tamas' request was to have one extractor per JVM language in a separate
project. But due to his current API changes, this would be a lot of work to do!
[https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc]
especially you'd have to mantain multiple versions (<3.7, >= 3.7).
h2. Downsides of custom extractors
# Setting up as a user is complicated, see this example:
{code:java}
org.apache.maven.plugins
maven-plugin-plugin
com.carrotgarden.maven
maven-plugin-tools-annotations
[1,2)
bintray
java-annotations-extra
{code}
# More dependencies to update!
# You need two versions: One for plugin-tools <3.7 and one for plugin tools
>=3.7 due to API incompatiblity (new interface methods without defaults).
h2. Alternative: Provide @Description annotation
That said, just adding a description mojo with fields "description", "since",
"deprecated" would be the easiest way to solve this. It is easily backwards
compatible (just use javadoc if no annotation is present) and it is similar to
what OpenAPI annotations do - they do not parse javadoc either. Besides,
Javadoc can have a different level of detail comparing to the Mojo Descrption.
So a separation might be feasible after all!
This enables scala, kotlin and groovy plugins to be written with full
documentation.
was:
Hey all!
This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247
which was closed as won't fix.
I tried to implement a kotlin parser, but it is really hard to do so, because
you cannot reuse any of the Methods from JavaAnnotationsParser.
That said, someone used messy reflections for this:
[https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67]
Trying this without reflection will lead you to iterate over files again and
again (here's a barebone):
[https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87]
Tamas' request was to have one extractor per JVM language in a separate
project. But due to his current API changes, this would be a lot of work to do!
[https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc]
especially you'd have to mantain multiple versions (<3.7, >= 3.7).
Alternative: Provide @Description annotation
That said, just adding a description mojo with fields "description", "since",
"deprecated" would be the easiest way to solve this. It is easily backwards
compatible (just use javadoc if no annotation is present) and it is similar to
what OpenAPI annotations do - they do not parse javadoc either. Besides,
Javadoc can have a different level of detail comparing to the Mojo Descrption.
So a separation might be feasible after all!
This enables scala, kotlin and groovy plugins to be written with full
documentation.
> MojoDescription annotation
> --
>
> Key: MPLUGIN-426
> URL: https://issues.apache.org/jira/browse/MPLUGIN-426
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: maven-plugin-annotations, Plugin Plugin
>Affects Versions: 3.4, 3.5.2, 3.6.4
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hey all!
> h2. Overview
> This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247
> which was closed as won't fix.
> I tried to implement a kotlin parser, but
[jira] [Updated] (MPLUGIN-426) MojoDescription annotation
[ https://issues.apache.org/jira/browse/MPLUGIN-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MPLUGIN-426: - Description: Hey all! This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247 which was closed as won't fix. I tried to implement a kotlin parser, but it is really hard to do so, because you cannot reuse any of the Methods from JavaAnnotationsParser. That said, someone used messy reflections for this: [https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67] Trying this without reflection will lead you to iterate over files again and again (here's a barebone): [https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87] Tamas' request was to have one extractor per JVM language in a separate project. But due to his current API changes, this would be a lot of work to do! [https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc] especially you'd have to mantain multiple versions (<3.7, >= 3.7). Alternative: Provide @Description annotation That said, just adding a description mojo with fields "description", "since", "deprecated" would be the easiest way to solve this. It is easily backwards compatible (just use javadoc if no annotation is present) and it is similar to what OpenAPI annotations do - they do not parse javadoc either. Besides, Javadoc can have a different level of detail comparing to the Mojo Descrption. So a separation might be feasible after all! This enables scala, kotlin and groovy plugins to be written with full documentation. was: Hey all! This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247 which was closed as won't fix. I tried to implement a kotlin parser, but it is really hard to do so, because you cannot reuse any of the Methods from JavaAnnotationsParser. That said, someone used messy reflections for this: [https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67] Trying this without reflection will lead you to iterate over files again and again (here's a barebone): [https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87] Tamas' request was to have one extractor per JVM language in a separate project. But due to his current API changes, this would be a lot of work to do! [https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc] especially you'd have to mantain multiple versions (<3.7, >= 3.7). That said, just adding a description mojo with fields "description", "since", "deprecated" would be the easiest way to solve this. It is easily backwards compatible (just use javadoc if no annotation is present) and it is similar to what OpenAPI annotations do - they do not parse javadoc either. Besides, Javadoc can have a different level of detail comparing to the Mojo Descrption. So a separation might be feasible after all! This enables scala, kotlin and groovy plugins to be written with full documentation. > MojoDescription annotation > -- > > Key: MPLUGIN-426 > URL: https://issues.apache.org/jira/browse/MPLUGIN-426 > Project: Maven Plugin Tools > Issue Type: New Feature > Components: maven-plugin-annotations, Plugin Plugin >Affects Versions: 3.4, 3.5.2, 3.6.4 >Reporter: Benjamin Marwell >Priority: Major > > Hey all! > This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247 > which was closed as won't fix. > I tried to implement a kotlin parser, but it is really hard to do so, because > you cannot reuse any of the Methods from JavaAnnotationsParser. > That said, someone used messy reflections for this: > [https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67] > Trying this without reflection will lead you to iterate over files again and > again (here's a barebone): > [https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87] > Tamas' request was to have one extractor per JVM language in a separate > project. But due to his current API changes, this would be a lot of work to > do! > [https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc] > especially
[jira] [Created] (MPLUGIN-426) MojoDescription annotation
Benjamin Marwell created MPLUGIN-426: Summary: MojoDescription annotation Key: MPLUGIN-426 URL: https://issues.apache.org/jira/browse/MPLUGIN-426 Project: Maven Plugin Tools Issue Type: New Feature Components: maven-plugin-annotations, Plugin Plugin Affects Versions: 3.6.4, 3.5.2, 3.4 Reporter: Benjamin Marwell Hey all! This is actually reopening https://issues.apache.org/jira/browse/MPLUGIN-247 which was closed as won't fix. I tried to implement a kotlin parser, but it is really hard to do so, because you cannot reuse any of the Methods from JavaAnnotationsParser. That said, someone used messy reflections for this: [https://github.com/random-maven/maven-plugin-tools-annotations/blob/35371c19004622645f87c35c2317a7c860b924a5/src/main/java/com/carrotgarden/maven/tools/Extractor.java#L57-L67] Trying this without reflection will lead you to iterate over files again and again (here's a barebone): [https://github.com/bmarwell/maven-plugin-tools-kotlin-extractor/blob/main/src/main/java/org/apache/maven/tools/plugin/extractor/kotlin/KotlinKdocExtractor.java#L80-L87] Tamas' request was to have one extractor per JVM language in a separate project. But due to his current API changes, this would be a lot of work to do! [https://github.com/apache/maven-plugin-tools/commit/ba8eb2dc52fb406f9e3897c9577f0bf0d4b0f0fc] especially you'd have to mantain multiple versions (<3.7, >= 3.7). That said, just adding a description mojo with fields "description", "since", "deprecated" would be the easiest way to solve this. It is easily backwards compatible (just use javadoc if no annotation is present) and it is similar to what OpenAPI annotations do - they do not parse javadoc either. Besides, Javadoc can have a different level of detail comparing to the Mojo Descrption. So a separation might be feasible after all! This enables scala, kotlin and groovy plugins to be written with full documentation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MEAR-269) Generate Websphere Deployment Descriptors
[ https://issues.apache.org/jira/browse/MEAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17614446#comment-17614446 ] Benjamin Marwell commented on MEAR-269: --- The files I mentioned are part of a war file. So because you don't know the ear file at this point, I don't see how those files could be generated. They're easily handwritten anyway. As the OP never answered, I'd say: close this one. > Generate Websphere Deployment Descriptors > - > > Key: MEAR-269 > URL: https://issues.apache.org/jira/browse/MEAR-269 > Project: Maven EAR Plugin > Issue Type: New Feature >Reporter: David Gautier >Priority: Minor > Fix For: waiting-for-feedback > > > Websphere deployment descriptors could be generated based on application.xml > and web.xml > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPOM-310) Replace Google Analytics with ASF Matomo in documentation
[ https://issues.apache.org/jira/browse/MPOM-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505280#comment-17505280 ] Benjamin Marwell commented on MPOM-310: --- No. This is the Maven POM. The Apache pom is a different project. > Replace Google Analytics with ASF Matomo in documentation > - > > Key: MPOM-310 > URL: https://issues.apache.org/jira/browse/MPOM-310 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-25 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-26 > > > ASF Parent POM documentation is published to Maven site: it need to follow > Maven's tracking practice that is changing with MPOM-300 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MPOM-300) Replace Google Analytics with ASF Matomo
[ https://issues.apache.org/jira/browse/MPOM-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell closed MPOM-300. - > Replace Google Analytics with ASF Matomo > > > Key: MPOM-300 > URL: https://issues.apache.org/jira/browse/MPOM-300 > Project: Maven POMs > Issue Type: Improvement >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > > While GA is still allowed according to the [ASF Privacy > Policy|https://www.apache.org/foundation/policies/privacy.html], there's now > [an ASF Matomo instance|https://matomo.privacy.apache.org/]. > * Matomo doesn't track full IPs, doesn't track sessions after closing the > browser, etc. > * Additionally, GA is already illegal in some countries,, like France. > Let's replace the GA code with Matomo. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MPOM-300) Replace Google Analytics with ASF Matomo
[ https://issues.apache.org/jira/browse/MPOM-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell reassigned MPOM-300: - Assignee: Benjamin Marwell > Replace Google Analytics with ASF Matomo > > > Key: MPOM-300 > URL: https://issues.apache.org/jira/browse/MPOM-300 > Project: Maven POMs > Issue Type: Improvement >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > > While GA is still allowed according to the [ASF Privacy > Policy|https://www.apache.org/foundation/policies/privacy.html], there's now > [an ASF Matomo instance|https://matomo.privacy.apache.org/]. > * Matomo doesn't track full IPs, doesn't track sessions after closing the > browser, etc. > * Additionally, GA is already illegal in some countries,, like France. > Let's replace the GA code with Matomo. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MPOM-300) Replace Google Analytics with ASF Matomo
[ https://issues.apache.org/jira/browse/MPOM-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell resolved MPOM-300. --- Resolution: Fixed > Replace Google Analytics with ASF Matomo > > > Key: MPOM-300 > URL: https://issues.apache.org/jira/browse/MPOM-300 > Project: Maven POMs > Issue Type: Improvement >Reporter: Benjamin Marwell >Priority: Major > > While GA is still allowed according to the [ASF Privacy > Policy|https://www.apache.org/foundation/policies/privacy.html], there's now > [an ASF Matomo instance|https://matomo.privacy.apache.org/]. > * Matomo doesn't track full IPs, doesn't track sessions after closing the > browser, etc. > * Additionally, GA is already illegal in some countries,, like France. > Let's replace the GA code with Matomo. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502117#comment-17502117
]
Benjamin Marwell commented on MRESOLVER-246:
Ok, understood.
Maybe what I actually want is "let's update the Maven2 repository layout to
also support more modern hashes".
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MPOM-300) Replace Google Analytics with ASF Matomo
Benjamin Marwell created MPOM-300: - Summary: Replace Google Analytics with ASF Matomo Key: MPOM-300 URL: https://issues.apache.org/jira/browse/MPOM-300 Project: Maven POMs Issue Type: Improvement Reporter: Benjamin Marwell While GA is still allowed according to the [ASF Privacy Policy|https://www.apache.org/foundation/policies/privacy.html], there's now [an ASF Matomo instance|https://matomo.privacy.apache.org/]. * Matomo doesn't track full IPs, doesn't track sessions after closing the browser, etc. * Additionally, GA is already illegal in some countries,, like France. Let's replace the GA code with Matomo. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MDEPLOY-290) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MDEPLOY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501331#comment-17501331
]
Benjamin Marwell commented on MDEPLOY-290:
--
>From the slack I learned this should be moved to the resolver plugin.
> m-deploy-p will create hashes for hashes
>
>
> Key: MDEPLOY-290
> URL: https://issues.apache.org/jira/browse/MDEPLOY-290
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2, 3.0.0-M2
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (MDEPLOY-290) m-deploy-p will create hashes for hashes
[ https://issues.apache.org/jira/browse/MDEPLOY-290 ]
Benjamin Marwell deleted comment on MDEPLOY-290:
--
was (Author: mampf86):
Shiro set-up
> m-deploy-p will create hashes for hashes
>
>
> Key: MDEPLOY-290
> URL: https://issues.apache.org/jira/browse/MDEPLOY-290
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2, 3.0.0-M2
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEPLOY-290) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MDEPLOY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501295#comment-17501295
]
Benjamin Marwell commented on MDEPLOY-290:
--
Shiro set-up
> m-deploy-p will create hashes for hashes
>
>
> Key: MDEPLOY-290
> URL: https://issues.apache.org/jira/browse/MDEPLOY-290
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2, 3.0.0-M2
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MDEPLOY-290) m-deploy-p will create hashes for hashes
Benjamin Marwell created MDEPLOY-290:
Summary: m-deploy-p will create hashes for hashes
Key: MDEPLOY-290
URL: https://issues.apache.org/jira/browse/MDEPLOY-290
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 3.0.0-M2, 2.8.2
Reporter: Benjamin Marwell
Hi everyone,
recent ASF parent pom will create hashes for source-release-zip files using the
checksum-maven-plugin.
However, the SHIRO project decided to hash ALL artifacts:
{code:xml}
org.apache.maven.plugins
maven-gpg-plugin
**/*.md5
**/*.sha1
**/*.sha256
**/*.sha512
**/*.asc
**/*.sha3512
net.nicoulaj.maven.plugins
checksum-maven-plugin
1.11
source-release-checksum
none
main-artifact-checksum
verify
artifacts
SHA-256
SHA-512
SHA3-512
false
true
{code}
Now as you can see, gpg plugin had to be extended, but we also create *.sha3512
files. Those and all other hashes are being hashed by the deploy plugin, though:
{code}
$ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
{code}
Notice the *.sha512.md1 and *.sha512.sha1 files.
Currently there is no exclusion possible.
Therefore:
* Let's add an exclusion parameter for hashing, similar to gpg's one.
* set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNGSITE-480) IDE Codestyle vs Maven Checkstyle: a bossfight
[
https://issues.apache.org/jira/browse/MNGSITE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493127#comment-17493127
]
Benjamin Marwell commented on MNGSITE-480:
--
need to remove the "LAMBDA" token from
[https://checkstyle.sourceforge.io/config_blocks.html#LeftCurly] check.
Maybe even add a second "LeftCurly" check with tokens="LAMBDA" option="eol".
> IDE Codestyle vs Maven Checkstyle: a bossfight
> --
>
> Key: MNGSITE-480
> URL: https://issues.apache.org/jira/browse/MNGSITE-480
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Tamás Cservenák
>Priority: Major
>
> Codestyle updated in MNGSITE-465 for Idea has discrepancies wrt checkstyle
> plugin rules.
>
> Typical example:
> IDEA IDE reformat result:
> {noformat}
> StreamSupport.stream( iteratorSearchResponse.iterator().spliterator(), false )
> .sorted( ArtifactInfo.VERSION_COMPARATOR ).forEach( ai -> {
> artifactInfos.add( ai );
> page.add( convert( ai, null ) );
> } );
> {noformat}
> But, checktyle:
> {noformat}
> [ERROR]
> src/main/java/org/apache/maven/index/search/backend/indexer/internal/IndexerCoreSearchBackendImpl.java:[127,83]
> (blocks) LeftCurly: '{' at column 83 should be on a new line.{noformat}
> In short, for me it looks like our checkstyle is too rigid, unprepared for
> Java 8 lambdas? (as IMHO the code snippet above with curly on next line would
> look awkward).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483137#comment-17483137
]
Benjamin Marwell commented on MSHARED-1032:
---
`canGenrateReport()` is actually called twice: in `execute()` and then in
`generate()` again (which is also called by `execute()`).
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the [`{{AbstractReportMojo}}` in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [`{{canGenerateReport()}}` from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7393) API change: let `canGenerateReport` throw an Exception
[
https://issues.apache.org/jira/browse/MNG-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480003#comment-17480003
]
Benjamin Marwell commented on MNG-7393:
---
You should know better than me that this is not a good idea, especially in this
case. A {{MojoExecutionException}} and/or {{MavenReportException}} (wrapped
around the {{{}IOException{}}}) is much better handled and printed.
I am not really sure what to make from your comment. Yes, I know I *could*
throw a {{{}RuntimeException{}}}. But as you could have guessed from the fact
that I created this issue in the first place, I sincerely think changing the
API is a cleaner solution here. ;)
> API change: let `canGenerateReport` throw an Exception
> --
>
> Key: MNG-7393
> URL: https://issues.apache.org/jira/browse/MNG-7393
> Project: Maven
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> the `{{{}AbstractReportMojo{}}}` declares a method
> `{{{}canGenerateReport(){}}}`.
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7393) API change: let `canGenerateReport` throw an Exception
[
https://issues.apache.org/jira/browse/MNG-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MNG-7393:
--
Description:
Hi everyone,
the `{{{}AbstractReportMojo{}}}` declares a method
`{{{}canGenerateReport(){}}}`.
However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}} or
{{{}MavenReportEx{}}}, which is most unfortunate.
It is being used twice:
Once in {{execute() throws MojoExEx}}
and in
{{generate() throws MavenReportEx}} (and is called by execute()).
This way, there is no way for reporting plugins to scan for files, because
{{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot be
wrapped. However, the {{IOException}} from that method is useless anyway,
because it is never declared in any methods it calls.
Therefore please consider:
* Declaring any Exception on `{{{}canGenerateReports(){}}}`
* Removing the declared {{IOException}} in PlexusUtils ([PR
exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
Maven-Utils (issue: tbd).
Thanks!
was:
Hi everyone,
the `AbstractReportMojo` declares a method `canGenerateReport`.
However, it is unable to throw any exceptions. Not even MojoExecutionEx or
MavenReportEx, which is most unfortunate.
It is being used twice:
Once in execute() throws MojoExEx
and in
generate() throws MavenReportEx (and is called by execute()).
This way, there is no way for reporting plugins to scan for files, because
FileUtils::getFiles DOES throw a IOException, which then cannot be wrapped.
However, the IOException from that method is useless anyway, because it is
never declared in any methods it calls.
Therefore please consider:
* Declaring any Exception on `canGenerateReports`
* Removing the declared IOException in PlexusUtils ([PR
exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
Maven-Utils (issue: tbd).
Thanks!
> API change: let `canGenerateReport` throw an Exception
> --
>
> Key: MNG-7393
> URL: https://issues.apache.org/jira/browse/MNG-7393
> Project: Maven
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> the `{{{}AbstractReportMojo{}}}` declares a method
> `{{{}canGenerateReport(){}}}`.
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MNG-7393) API change: let `canGenerateReport` throw an Exception
Benjamin Marwell created MNG-7393: - Summary: API change: let `canGenerateReport` throw an Exception Key: MNG-7393 URL: https://issues.apache.org/jira/browse/MNG-7393 Project: Maven Issue Type: Improvement Reporter: Benjamin Marwell Hi everyone, the `AbstractReportMojo` declares a method `canGenerateReport`. However, it is unable to throw any exceptions. Not even MojoExecutionEx or MavenReportEx, which is most unfortunate. It is being used twice: Once in execute() throws MojoExEx and in generate() throws MavenReportEx (and is called by execute()). This way, there is no way for reporting plugins to scan for files, because FileUtils::getFiles DOES throw a IOException, which then cannot be wrapped. However, the IOException from that method is useless anyway, because it is never declared in any methods it calls. Therefore please consider: * Declaring any Exception on `canGenerateReports` * Removing the declared IOException in PlexusUtils ([PR exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and Maven-Utils (issue: tbd). Thanks! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPOM-265) re-enable reproducible builds for ASF parent POM source-release.zip
[ https://issues.apache.org/jira/browse/MPOM-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378787#comment-17378787 ] Benjamin Marwell commented on MPOM-265: --- Hervé, Is this a good idea for a parent pom? Wouldn't all Apache projects not setting/overriding this property be having a problem? It is probably a similar question to what we had a month ago with the spring boot pom. The license from the parent pom is being inherited… > re-enable reproducible builds for ASF parent POM source-release.zip > --- > > Key: MPOM-265 > URL: https://issues.apache.org/jira/browse/MPOM-265 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-24 >Reporter: Herve Boutemy >Priority: Major > Fix For: ASF-25 > > > project.build.outputTimestamp property was removed in MPOM-255 > need to add it back for ASF parent POM source-release zip file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MDEP-622) dependency:go-offline does not respect excludeGroupIds
[ https://issues.apache.org/jira/browse/MDEP-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell closed MDEP-622. - Resolution: Duplicate > dependency:go-offline does not respect excludeGroupIds > -- > > Key: MDEP-622 > URL: https://issues.apache.org/jira/browse/MDEP-622 > Project: Maven Dependency Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Cosmin Stejerean >Priority: Major > > dependency:go-offline does not respect excludeGroupIds. Tested with 3.1.1. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAVADOC-642) Setting maven.javadoc.isoffline seems to have no effect
[
https://issues.apache.org/jira/browse/MJAVADOC-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17340121#comment-17340121
]
Benjamin Marwell commented on MJAVADOC-642:
---
Here is a sampel configuration:
{code:xml}
http://docs.oracle.com/javase/7/docs/api
http://static.netty.io/3.5/api
http://google-guice.googlecode.com/git/javadoc
http://fasterxml.github.com/jackson-databind/javadoc/2.0.4
https://developers.google.com/protocol-buffers/docs/reference/java
true
true
true
true
true
{code}
Output behind proxy:
{code}
[WARN] Error fetching link:
https://github.com/javaee/jaxb-spec/jaxb-api/apidocs. Ignored it.
[WARN] Error fetching link: http://www.slf4j.org/apidocs. Ignored it.
[WARN] Error fetching link: http://findbugs.sourceforge.net/apidocs. Ignored it.
[WARN] Error fetching link: http://cdi-spec.org/apidocs. Ignored it.
[WARN] Error fetching link: http://www.jqno.nl/equalsverifier/apidocs. Ignored
it.
[WARN] Error fetching link: https://checkerframework.org/apidocs. Ignored it.
[WARN] Error fetching link: https://junit.org/junit5/apidocs. Ignored it.
[WARN] Error fetching link: https://junit.org/junit5/apidocs. Ignored it.
[WARN] Error fetching link: http://hamcrest.org/JavaHamcrest/apidocs. Ignored
it.
[WARN] Error fetching link: https://github.com/mockito/mockito/apidocs. Ignored
it.
{code}
> Setting maven.javadoc.isoffline seems to have no effect
> ---
>
> Key: MJAVADOC-642
> URL: https://issues.apache.org/jira/browse/MJAVADOC-642
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.1
>Reporter: Thomas Cunningham
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I'm trying to work around MJAVADOC-641 and the proxy issues that we are
> having, and I'd like to set isOffline to true. I tried to do this my
> setting -Dmaven.javadoc.isOffline=true in my maven invocation, and it doesn't
> seem to take effect. Setting isOffline to true within the
> allows my build to succeed.
> Am I using the wrong command line property for isOffline?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-642) Setting maven.javadoc.isoffline seems to have no effect
[
https://issues.apache.org/jira/browse/MJAVADOC-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17340121#comment-17340121
]
Benjamin Marwell edited comment on MJAVADOC-642 at 5/6/21, 9:49 AM:
Here is a sample configuration:
{code:xml}
http://docs.oracle.com/javase/7/docs/api
http://static.netty.io/3.5/api
http://google-guice.googlecode.com/git/javadoc
http://fasterxml.github.com/jackson-databind/javadoc/2.0.4
https://developers.google.com/protocol-buffers/docs/reference/java
true
true
true
true
true
{code}
Output behind proxy:
{code}
[WARN] Error fetching link:
https://github.com/javaee/jaxb-spec/jaxb-api/apidocs. Ignored it.
[WARN] Error fetching link: http://www.slf4j.org/apidocs. Ignored it.
[WARN] Error fetching link: http://findbugs.sourceforge.net/apidocs. Ignored it.
[WARN] Error fetching link: http://cdi-spec.org/apidocs. Ignored it.
[WARN] Error fetching link: http://www.jqno.nl/equalsverifier/apidocs. Ignored
it.
[WARN] Error fetching link: https://checkerframework.org/apidocs. Ignored it.
[WARN] Error fetching link: https://junit.org/junit5/apidocs. Ignored it.
[WARN] Error fetching link: https://junit.org/junit5/apidocs. Ignored it.
[WARN] Error fetching link: http://hamcrest.org/JavaHamcrest/apidocs. Ignored
it.
[WARN] Error fetching link: https://github.com/mockito/mockito/apidocs. Ignored
it.
{code}
was (Author: mampf86):
Here is a sampel configuration:
{code:xml}
http://docs.oracle.com/javase/7/docs/api
http://static.netty.io/3.5/api
http://google-guice.googlecode.com/git/javadoc
http://fasterxml.github.com/jackson-databind/javadoc/2.0.4
https://developers.google.com/protocol-buffers/docs/reference/java
true
true
true
true
true
{code}
Output behind proxy:
{code}
[WARN] Error fetching link:
https://github.com/javaee/jaxb-spec/jaxb-api/apidocs. Ignored it.
[WARN] Error fetching link: http://www.slf4j.org/apidocs. Ignored it.
[WARN] Error fetching link: http://findbugs.sourceforge.net/apidocs. Ignored it.
[WARN] Error fetching link: http://cdi-spec.org/apidocs. Ignored it.
[WARN] Error fetching link: http://www.jqno.nl/equalsverifier/apidocs. Ignored
it.
[WARN] Error fetching link: https://checkerframework.org/apidocs. Ignored it.
[WARN] Error fetching link: https://junit.org/junit5/apidocs. Ignored it.
[WARN] Error fetching link: https://junit.org/junit5/apidocs. Ignored it.
[WARN] Error fetching link: http://hamcrest.org/JavaHamcrest/apidocs. Ignored
it.
[WARN] Error fetching link: https://github.com/mockito/mockito/apidocs. Ignored
it.
{code}
> Setting maven.javadoc.isoffline seems to have no effect
> ---
>
> Key: MJAVADOC-642
> URL: https://issues.apache.org/jira/browse/MJAVADOC-642
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.1
>Reporter: Thomas Cunningham
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I'm trying to work around MJAVADOC-641 and the proxy issues that we are
> having, and I'd like to set isOffline to true. I tried to do this my
> setting -Dmaven.javadoc.isOffline=true in my maven invocation, and it doesn't
> seem to take effect. Setting isOffline to true within the
> allows my build to succeed.
> Am I using the wrong command line property for isOffline?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MJDEPRSCAN-4) Add GH Actions
Benjamin Marwell created MJDEPRSCAN-4: - Summary: Add GH Actions Key: MJDEPRSCAN-4 URL: https://issues.apache.org/jira/browse/MJDEPRSCAN-4 Project: Maven JDeprScan Plugin Issue Type: Task Reporter: Benjamin Marwell Assignee: Benjamin Marwell Fix For: 3.0.0 Add GH actions Use tool provider as in the maven-jlink-plugin so we can test toolprovider calls from MR-Jars. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-455) preparePaths does not take toolchain into account when parsing module-info.class
[
https://issues.apache.org/jira/browse/MCOMPILER-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17282457#comment-17282457
]
Benjamin Marwell commented on MCOMPILER-455:
upstream issue
> preparePaths does not take toolchain into account when parsing
> module-info.class
>
>
> Key: MCOMPILER-455
> URL: https://issues.apache.org/jira/browse/MCOMPILER-455
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Benjamin Marwell
>Priority: Blocker
> Labels: modularization, module, modules, toolchain, toolchains
>
> If you re-compile modules (e.g. via second execution of mvn compile), the
> CompileMojo tries to read existing module descriptors. If you used toolchains
> to compile those, this process will fail:
>
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
> major.minor version 59.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
> (BinaryModuleInfoParser.java:35)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:45)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths
> (LocationManager.java:127)
> at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths
> (CompilerMojo.java:238)
> at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
> (AbstractCompilerMojo.java:792)
> at org.apache.maven.plugin.compiler.CompilerMojo.execute
> (CompilerMojo.java:187)
> {code}
> Test project: https://github.com/torakiki/testme
> Reproduce:
> * git clone https://github.com/torakiki/testme.git
> * cd testme
> * mvn compile
> * mvn compile
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MCOMPILER-455) preparePaths does not take toolchain into account when parsing module-info.class
Benjamin Marwell created MCOMPILER-455:
--
Summary: preparePaths does not take toolchain into account when
parsing module-info.class
Key: MCOMPILER-455
URL: https://issues.apache.org/jira/browse/MCOMPILER-455
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.8.1
Reporter: Benjamin Marwell
If you re-compile modules (e.g. via second execution of mvn compile), the
CompileMojo tries to read existing module descriptors. If you used toolchains
to compile those, this process will fail:
{code:java}
Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
major.minor version 59.0
at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
(ModuleInfo.java:1091)
at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
(BinaryModuleInfoParser.java:35)
at
org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
(AbstractBinaryModuleInfoParser.java:45)
at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths
(LocationManager.java:127)
at org.apache.maven.plugin.compiler.CompilerMojo.preparePaths
(CompilerMojo.java:238)
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
(AbstractCompilerMojo.java:792)
at org.apache.maven.plugin.compiler.CompilerMojo.execute
(CompilerMojo.java:187)
{code}
Test project: https://github.com/torakiki/testme
Reproduce:
* git clone https://github.com/torakiki/testme.git
* cd testme
* mvn compile
* mvn compile
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-4559) MAVEN_OPTS are incorrectly resolved in Unix
[ https://issues.apache.org/jira/browse/MNG-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276253#comment-17276253 ] Benjamin Marwell commented on MNG-4559: --- eval is necessary. Eg look at this IBM code, they also need to support ksh (which is a posix shell used by AIX as a default): [https://github.com/OpenLiberty/open-liberty/blob/bd54569d3322c4321a7dda4fcf94d65f85bf13bf/dev/com.ibm.ws.kernel.boot.ws-server/publish/bin/server#L695-L716] Follow the eval methods and how they define them. (hint: EPLv1). (hint 2: they support spaces and comments) > MAVEN_OPTS are incorrectly resolved in Unix > --- > > Key: MNG-4559 > URL: https://issues.apache.org/jira/browse/MNG-4559 > Project: Maven > Issue Type: Bug > Components: Command Line >Affects Versions: 2.2.1, 3.0.5 > Environment: OS: Linux, 2.6.32-11-generic, amd64. > Java: 1.6.0_17 > Also Operating System = Mac OS X version 10.9.2 running on x86_64 > Java; VM; Vendor = 1.7.0_51 >Reporter: Maxim Podkolzine >Priority: Major > > I'm trying to pass a quoted parameter through MAVEN_OPTS, e.g. > MAVEN_OPTS="-Dfoo='bar baz'" > As a result the quotes are not resolved, causing Java failure: > Exception in thread "main" java.lang.NoClassDefFoundError: baz' > ... > I couldn't figure out a way to make it work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
