[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Description: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. To my best understanding, when it comes to transitive dependencies, both "nearest first" and "declared first" are random variables which user can't control unless they re-declare all the dependencies in their local pom. I suggest Maven should not use random variables like "dependency depth" or "dependency order" to drive conflict resolution. was: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy]
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Description: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Below I list reasons why both "nearest wins" and "declared first" yield hard-to-predict behaviours, and they are likely to produce dependency downgrades and the associated runtime errors. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. was: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" >
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Description: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The step to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. was: Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The steps to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type:
[jira] [Updated] (MNG-7852) Use all the versions for dependency resolution rather than "nearest first" or "declared first"
[ https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated MNG-7852: --- Summary: Use all the versions for dependency resolution rather than "nearest first" or "declared first" (was: Use all the versions for dependency resolution rather than "the first ones") > Use all the versions for dependency resolution rather than "nearest first" or > "declared first" > -- > > Key: MNG-7852 > URL: https://issues.apache.org/jira/browse/MNG-7852 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Vladimir Sitnikov >Priority: Major > > Currently, Maven uses "nearest first", "declared first" rules for conflict > resolution: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > I suggest those rules are removed since they produce hard to reason > resolutions for transitive dependencies. > Here are some examples: > 1) "Nearest first". Even though the rule sounds easy, it is not something the > users can control. For instance, if the project does not use Guava library, > some of the transitive dependencies could add a dependency on Guava. The user > has no control which dependency would be "the nearest" to declare Guava, so > user has literally no way to tell which Guava version will be used. > The only workaround I see for the users is to declare Guava dependency > explicitly even though the project does not need it directly. It sounds like > Maven requires users to re-declare all the possible dependencies, including > the runtime-only ones. > 2) "declared first". Of course, dependency order matters for classpath order, > however, it is not predictable in practice, and it might result in > downgrading dependencies. Imagine the project does not use Guice. However, > transitive dependencies might use Guice. At the same time, they might start > using Guice and stop using Guice, so the user can never tell which will be > the first project that uses Guice. Unfortunately, in Maven, the first project > that declares dependency wins, so it might easily be the case that the first > mention of Guice will reference outdated version that would be incompatible > with the newer one required in another dependency. > 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing > something like NoSuchMethodError at the runtime. The steps to reproduce is to > add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis > in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md > Long story short, sigstore-java does not depend on protobuf-java directly, > however, sigstore-java depends on several third-party libraries that > eventually depend on protobuf-java. Maven's "the first wins" behaviour > results in incoherent set of protobuf dependencies on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7852) Use all the versions for dependency resolution rather than "the first ones"
Vladimir Sitnikov created MNG-7852: -- Summary: Use all the versions for dependency resolution rather than "the first ones" Key: MNG-7852 URL: https://issues.apache.org/jira/browse/MNG-7852 Project: Maven Issue Type: Improvement Components: Dependencies Reporter: Vladimir Sitnikov Currently, Maven uses "nearest first", "declared first" rules for conflict resolution: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I suggest those rules are removed since they produce hard to reason resolutions for transitive dependencies. Here are some examples: 1) "Nearest first". Even though the rule sounds easy, it is not something the users can control. For instance, if the project does not use Guava library, some of the transitive dependencies could add a dependency on Guava. The user has no control which dependency would be "the nearest" to declare Guava, so user has literally no way to tell which Guava version will be used. The only workaround I see for the users is to declare Guava dependency explicitly even though the project does not need it directly. It sounds like Maven requires users to re-declare all the possible dependencies, including the runtime-only ones. 2) "declared first". Of course, dependency order matters for classpath order, however, it is not predictable in practice, and it might result in downgrading dependencies. Imagine the project does not use Guice. However, transitive dependencies might use Guice. At the same time, they might start using Guice and stop using Guice, so the user can never tell which will be the first project that uses Guice. Unfortunately, in Maven, the first project that declares dependency wins, so it might easily be the case that the first mention of Guice will reference outdated version that would be incompatible with the newer one required in another dependency. 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing something like NoSuchMethodError at the runtime. The steps to reproduce is to add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md Long story short, sigstore-java does not depend on protobuf-java directly, however, sigstore-java depends on several third-party libraries that eventually depend on protobuf-java. Maven's "the first wins" behaviour results in incoherent set of protobuf dependencies on the classpath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7842) Keep using transitive dependencies even if one of the declarations misses a version
[
https://issues.apache.org/jira/browse/MNG-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747755#comment-17747755
]
Vladimir Sitnikov commented on MNG-7842:
{quote}Maven does not consider "partial models", it considers "model" that is
successfully built (and validated){quote}
That is not true.
Maven considers the partial models, and it discards the information.
Cosider:
A) User declares dependency without a version. Maven would fail the build with
"Some problems were encountered while processing the POMs.."
B) User declares dependency that references a dependency without a version.
Maven happily performs a build ignoring **all** the dependencies in the pom
that happens to contain "versionless" dependency.
{quote} Also, to have depMgmt applied, you have to have Model to apply to{quote}
Could you please rephrase so I could better understand what you suggest?
What I say is that **even if I declare dependencyManagement** locally, Maven
still ignores the pom that contains "versionless dependency".
> Keep using transitive dependencies even if one of the declarations misses a
> version
> ---
>
> Key: MNG-7842
> URL: https://issues.apache.org/jira/browse/MNG-7842
> Project: Maven
> Issue Type: Improvement
> Components: Core, Dependencies
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> I have a problem that Maven discards **all** transitive dependencies when a
> single of them misses {{}}. It breaks workflows, and it is not clear
> why Maven behaves like that.
> I'm using Maven 3.8.6.
> Sample:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> org.example
> TestBugMaven
> 1.0-SNAPSHOT
>
> 17
> 17
> UTF-8
>
>
>
> org.apache.jmeter
> ApacheJMeter_core
> 5.6.1
>
>
>
> {code}
> Test: {{mvn dependency:tree}}
> Output:
> {noformat}
> [WARNING] The POM for org.apache.jmeter:ApacheJMeter_core:jar:5.6.1 is
> invalid, transitive dependencies (if any) will not be available, enable debug
> logging for more details
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ TestBugMaven ---
> [INFO] org.example:TestBugMaven:jar:1.0-SNAPSHOT
> [INFO] \- org.apache.jmeter:ApacheJMeter_core:jar:5.6.1:compile
> {noformat}
> Frankly speaking, I do not understand why Maven discards ALL transitive
> dependencies in case it observes a single one with "missing version".
> Note: adding {{dependencyManagement}} does not seem to fix the case, so it is
> even more confusing.
> The following still discards transitive dependencies:
> {code:xml}
>
>
>
> com.google.auto.service
> auto-service-annotations
> compile
> 1.1.1
>
>
>
>
>
> org.apache.jmeter
> ApacheJMeter_core
> 5.6.1
>
>
> {code}
--
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] [Commented] (MJLINK-64) Add-options double quoting
[
https://issues.apache.org/jira/browse/MJLINK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747650#comment-17747650
]
ASF GitHub Bot commented on MJLINK-64:
--
bmarwell commented on PR #78:
URL:
https://github.com/apache/maven-jlink-plugin/pull/78#issuecomment-1652408337
Closed in favour of https://github.com/apache/maven-jlink-plugin/pull/166
> 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
>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] [Commented] (MJLINK-64) Add-options double quoting
[
https://issues.apache.org/jira/browse/MJLINK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747651#comment-17747651
]
ASF GitHub Bot commented on MJLINK-64:
--
bmarwell closed pull request #78: [MJLINK-64] Fix addOptions arguments passing
URL: https://github.com/apache/maven-jlink-plugin/pull/78
> 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
>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] [Commented] (MJLINK-72) Remove common-lang3
[ https://issues.apache.org/jira/browse/MJLINK-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747649#comment-17747649 ] ASF GitHub Bot commented on MJLINK-72: -- bmarwell opened a new pull request, #167: URL: https://github.com/apache/maven-jlink-plugin/pull/167 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJLINK) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MJLINK-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJLINK-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). > 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)
[GitHub] [maven-jlink-plugin] bmarwell closed pull request #78: [MJLINK-64] Fix addOptions arguments passing
bmarwell closed pull request #78: [MJLINK-64] Fix addOptions arguments passing URL: https://github.com/apache/maven-jlink-plugin/pull/78 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] bmarwell opened a new pull request, #167: [MJLINK-72] remove commons-lang3
bmarwell opened a new pull request, #167: URL: https://github.com/apache/maven-jlink-plugin/pull/167 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJLINK) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MJLINK-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJLINK-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJLINK-64) Add-options double quoting
[
https://issues.apache.org/jira/browse/MJLINK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747638#comment-17747638
]
ASF GitHub Bot commented on MJLINK-64:
--
bmarwell commented on PR #166:
URL:
https://github.com/apache/maven-jlink-plugin/pull/166#issuecomment-1652348371
Todo in another PR: Add fork mode to make it easy to test. The fork could
just call the same methods as the toolchain.
> 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
>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)
[GitHub] [maven-jlink-plugin] bmarwell opened a new pull request, #166: [MJLINK-64] add quoting on forking
bmarwell opened a new pull request, #166: URL: https://github.com/apache/maven-jlink-plugin/pull/166 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJLINK) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MJLINK-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJLINK-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJLINK-64) Add-options double quoting
[
https://issues.apache.org/jira/browse/MJLINK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747619#comment-17747619
]
ASF GitHub Bot commented on MJLINK-64:
--
bmarwell opened a new pull request, #166:
URL: https://github.com/apache/maven-jlink-plugin/pull/166
Following this checklist to help us incorporate your
contribution quickly and easily:
- [X] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MJLINK) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line
and body.
- [X] Format the pull request title like `[MJLINK-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MJLINK-XXX` with the appropriate JIRA issue. Best
practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [X] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [X] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [X] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [X] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [X] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> 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
>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] [Commented] (MSITE-971) Site generation not resolving git.commit.time
[
https://issues.apache.org/jira/browse/MSITE-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747573#comment-17747573
]
Michael Osipov commented on MSITE-971:
--
Looking at {{help:effective-pom}} the output isn't interpolated as well:
{noformat}
${git.commit.id.describe};
${git.commit.time}
-MM-dd
HH:mm:ssZ
true
17
17
17
3.8.8
${git.commit.time}
UTF-8
UTF-8
{noformat}
So I'd say that the behavior of Maven Site Plugin is consistent with the rest.
Wether it should be fully interpolated is another question. One could add the
same approach as done in {{DefaultSiteTool}}. I wonder whether there is a
better solution to this. I don't want to add special handling just for one
property...
> Site generation not resolving git.commit.time
> -
>
> Key: MSITE-971
> URL: https://issues.apache.org/jira/browse/MSITE-971
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: property interpolation
>Affects Versions: 4.0.0-M9
> Environment: Windows 10 and FreeBSD
>Reporter: Brad Larrick
>Assignee: Michael Osipov
>Priority: Major
>
> I'm using git-commit-id-maven-plugin to set project.build.outputTimestamp as
> suggested in the Maven Guide Configuring for Reproducible Builds. I've
> included the plugin in my pom and including the following property definition:
>
> {code:java}
> ${git.commit.time}{code}
>
> When I generate the site, the plugin fails with the message:
> {{site failed: Invalid project.build.outputTimestamp value
> '${git.commit.time}}}
> This configuration works properly in the maven-jar-plugin, so I did some
> investigation. The jar plugin is getting the outputTimestamp as a mojo
> parameter:
>
> {code:java}
> @Parameter( defaultValue = "${project.build.outputTimestamp}" )
> private String outputTimestamp;
> {code}
> This works properly, with outputTimestamp set to the last commit time.
> In the site-plugin code, the outputTimestamp is being pulled from the project
> properties:
> {code:java}
> String outputTimestamp =
> p.getProperties().getProperty("project.build.outputTimestamp");{code}
> In the case the property hasn't been resolved and the returned string is
> ${git.commit.time}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-389) Drop deprecated logging facade
Tamas Cservenak created MRESOLVER-389: - Summary: Drop deprecated logging facade Key: MRESOLVER-389 URL: https://issues.apache.org/jira/browse/MRESOLVER-389 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 1.10.0 There is some logging facade (unused) deprecated since long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747558#comment-17747558 ] ASF GitHub Bot commented on MRESOLVER-387: -- cstamas commented on PR #319: URL: https://github.com/apache/maven-resolver/pull/319#issuecomment-1651969030 Supplier will need to pick up changes from here https://github.com/apache/maven-resolver/pull/321 > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747556#comment-17747556 ] ASF GitHub Bot commented on MRESOLVER-386: -- cstamas opened a new pull request, #321: URL: https://github.com/apache/maven-resolver/pull/321 All injection points are public and deprecate all def ctors (where ctor injection used). --- https://issues.apache.org/jira/browse/MRESOLVER-386 > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > Example: DF and BF collector ctors: The two ctors (are also injected) are > package protected, making integrating code forced to use deprecated no-arg > ctor. > Actually, make sure all injection points are public as well and deprecate all > def ctors (where ctor injection used). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #321: [MRESOLVER-386] Make all injected ctors public, deprecate def ctors
cstamas opened a new pull request, #321: URL: https://github.com/apache/maven-resolver/pull/321 All injection points are public and deprecate all def ctors (where ctor injection used). --- https://issues.apache.org/jira/browse/MRESOLVER-386 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-386: -- Description: Example: DF and BF collector ctors: The two ctors (are also injected) are package protected, making integrating code forced to use deprecated no-arg ctor. Actually, make sure all injection points are public as well and deprecate all def ctors (where ctor injection used). was: The two ctors (are also injected) are package protected, making integrating code forced to use deprecated no-arg ctor. Actually, make sure all injection points are public as well. > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > Example: DF and BF collector ctors: The two ctors (are also injected) are > package protected, making integrating code forced to use deprecated no-arg > ctor. > Actually, make sure all injection points are public as well and deprecate all > def ctors (where ctor injection used). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-386: -- Summary: Make all injected ctors public, deprecate all def ctors (was: Make BF and DF collector ctors public) > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > The two ctors (are also injected) are package protected, making integrating > code forced to use deprecated no-arg ctor. > Actually, make sure all injection points are public as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSOURCES-140) Build fails when using install deploy
[ https://issues.apache.org/jira/browse/MSOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MSOURCES-140: - Description: By configuration maven-source-plugin is bound to verify phase. When executing commands like mvn install deploy, which includes phase verify 2 times, the build fails with error "We have duplicated artifacts attached." - it worked with 3.2.1 When just using mvn deploy it works. I know install and deploy together are redundant but in many build pipelines it is used that way and maven as such also allows the combination. Probably caused by MSOURCES-121 was: By configuration maven-source-plugin is bound to verify phase. When executing commands like mvn install deploy, which includes phase verify 2 times, the build fails with error "We have duplicated artifacts attached." - it worked with 3.2.1 When just using mvn deploy it works. I know install and deploy together are redundant but in many build pipelines it is used that way and maven as such also allows the combination. Probably caused by MSOURCE-121 > Build fails when using install deploy > - > > Key: MSOURCES-140 > URL: https://issues.apache.org/jira/browse/MSOURCES-140 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Joern >Priority: Minor > > By configuration maven-source-plugin is bound to verify phase. > When executing commands like mvn install deploy, which includes phase verify > 2 times, the build fails with error "We have duplicated artifacts attached." > - it worked with 3.2.1 > When just using mvn deploy it works. > I know install and deploy together are redundant but in many build pipelines > it is used that way and maven as such also allows the combination. > Probably caused by MSOURCES-121 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSOURCES-140) Build fails when using install deploy
Joern created MSOURCES-140: -- Summary: Build fails when using install deploy Key: MSOURCES-140 URL: https://issues.apache.org/jira/browse/MSOURCES-140 Project: Maven Source Plugin Issue Type: Bug Affects Versions: 3.3.0 Reporter: Joern By configuration maven-source-plugin is bound to verify phase. When executing commands like mvn install deploy, which includes phase verify 2 times, the build fails with error "We have duplicated artifacts attached." - it worked with 3.2.1 When just using mvn deploy it works. I know install and deploy together are redundant but in many build pipelines it is used that way and maven as such also allows the combination. Probably caused by MSOURCE-121 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] candrews commented on pull request #1210: [MNG-7851] Improve error message when modelVersion is 4.0
candrews commented on PR #1210: URL: https://github.com/apache/maven/pull/1210#issuecomment-1651879214 > And to do what? I don't see where is the error message adjusted... what do i miss? The new test case at https://github.com/apache/maven/blob/78da8ff662d9c9e0ba87aa2138114d8fd393855c/maven-model-builder/src/test/java/org/apache/maven/model/validation/DefaultModelValidatorTest.java#L120 demonstrates how the message changes. Before this PR, the message in this case is `'modelVersion' of '4.0' is newer than the versions supported by this version of Maven: [4.0.0]. Building this project requires a newer version of Maven.` And with this PR, as this test case proves, the error message is `'modelVersion' must be one of [4.0.0] but is '4.0'.`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7851) Error message when modelVersion is 4.0 is confusing
[
https://issues.apache.org/jira/browse/MNG-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747540#comment-17747540
]
ASF GitHub Bot commented on MNG-7851:
-
candrews commented on PR #1210:
URL: https://github.com/apache/maven/pull/1210#issuecomment-1651879214
> And to do what? I don't see where is the error message adjusted... what do
i miss?
The new test case at
https://github.com/apache/maven/blob/78da8ff662d9c9e0ba87aa2138114d8fd393855c/maven-model-builder/src/test/java/org/apache/maven/model/validation/DefaultModelValidatorTest.java#L120
demonstrates how the message changes. Before this PR, the message in this case
is `'modelVersion' of '4.0' is newer than the versions supported by this
version of Maven: [4.0.0]. Building this project requires a newer version of
Maven.` And with this PR, as this test case proves, the error message is
`'modelVersion' must be one of [4.0.0] but is '4.0'.`.
> Error message when modelVersion is 4.0 is confusing
> ---
>
> Key: MNG-7851
> URL: https://issues.apache.org/jira/browse/MNG-7851
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.3
>Reporter: Craig
>Priority: Minor
>
> When a pom with modelVersion 4.0 is referenced, such as this one:
> {code:xml}
>
> 4.0
> foo
> bar
> 0.1
>
> {code}
> The error message is:
> {{'modelVersion' of '4.0' is newer than the versions supported by this
> version of Maven: [4.0.0]. Building this project requires a newer version of
> Maven.}}
>
> That's misleading.
> A better error message would be:
> {{'modelVersion' must be one of [4.0.0] but is '4.0'.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7851) Error message when modelVersion is 4.0 is confusing
[
https://issues.apache.org/jira/browse/MNG-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747536#comment-17747536
]
ASF GitHub Bot commented on MNG-7851:
-
michael-o commented on PR #1210:
URL: https://github.com/apache/maven/pull/1210#issuecomment-1651870277
I take my first comment back. Thanks for this clarifiction.
> Error message when modelVersion is 4.0 is confusing
> ---
>
> Key: MNG-7851
> URL: https://issues.apache.org/jira/browse/MNG-7851
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.3
>Reporter: Craig
>Priority: Minor
>
> When a pom with modelVersion 4.0 is referenced, such as this one:
> {code:xml}
>
> 4.0
> foo
> bar
> 0.1
>
> {code}
> The error message is:
> {{'modelVersion' of '4.0' is newer than the versions supported by this
> version of Maven: [4.0.0]. Building this project requires a newer version of
> Maven.}}
>
> That's misleading.
> A better error message would be:
> {{'modelVersion' must be one of [4.0.0] but is '4.0'.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7851) Error message when modelVersion is 4.0 is confusing
[
https://issues.apache.org/jira/browse/MNG-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747538#comment-17747538
]
ASF GitHub Bot commented on MNG-7851:
-
cstamas commented on PR #1210:
URL: https://github.com/apache/maven/pull/1210#issuecomment-1651873331
> allowing it to compare "4", "4.0", and "4.0.0" to each other for example.
And to do what? I don't see where is the error message adjusted... what do i
miss?
> Error message when modelVersion is 4.0 is confusing
> ---
>
> Key: MNG-7851
> URL: https://issues.apache.org/jira/browse/MNG-7851
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.3
>Reporter: Craig
>Priority: Minor
>
> When a pom with modelVersion 4.0 is referenced, such as this one:
> {code:xml}
>
> 4.0
> foo
> bar
> 0.1
>
> {code}
> The error message is:
> {{'modelVersion' of '4.0' is newer than the versions supported by this
> version of Maven: [4.0.0]. Building this project requires a newer version of
> Maven.}}
>
> That's misleading.
> A better error message would be:
> {{'modelVersion' must be one of [4.0.0] but is '4.0'.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7851) Error message when modelVersion is 4.0 is confusing
[
https://issues.apache.org/jira/browse/MNG-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747529#comment-17747529
]
ASF GitHub Bot commented on MNG-7851:
-
candrews commented on PR #1210:
URL: https://github.com/apache/maven/pull/1210#issuecomment-1651857385
> I'd say that it should be fixed literal `4.0.0`.
Currently, Maven does require it to be the literal `4.0.0`:
https://github.com/apache/maven/blob/maven-3.9.4/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L138
https://github.com/apache/maven/blob/maven-3.9.4/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L1433
This PR adjusts the error message that is returned when attempts to use
non-`4.0.0` values are made.
> Error message when modelVersion is 4.0 is confusing
> ---
>
> Key: MNG-7851
> URL: https://issues.apache.org/jira/browse/MNG-7851
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.3
>Reporter: Craig
>Priority: Minor
>
> When a pom with modelVersion 4.0 is referenced, such as this one:
> {code:xml}
>
> 4.0
> foo
> bar
> 0.1
>
> {code}
> The error message is:
> {{'modelVersion' of '4.0' is newer than the versions supported by this
> version of Maven: [4.0.0]. Building this project requires a newer version of
> Maven.}}
>
> That's misleading.
> A better error message would be:
> {{'modelVersion' must be one of [4.0.0] but is '4.0'.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-388) Transport HTTP old codec proper override
[ https://issues.apache.org/jira/browse/MRESOLVER-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747527#comment-17747527 ] ASF GitHub Bot commented on MRESOLVER-388: -- cstamas opened a new pull request, #320: URL: https://github.com/apache/maven-resolver/pull/320 The depMgt is not applicable in certain cases. --- https://issues.apache.org/jira/browse/MRESOLVER-388 > Transport HTTP old codec proper override > > > Key: MRESOLVER-388 > URL: https://issues.apache.org/jira/browse/MRESOLVER-388 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > The codec was overridden, but not properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-388) Transport HTTP old codec proper override
Tamas Cservenak created MRESOLVER-388: - Summary: Transport HTTP old codec proper override Key: MRESOLVER-388 URL: https://issues.apache.org/jira/browse/MRESOLVER-388 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 1.10.0 The codec was overridden, but not properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[
https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747524#comment-17747524
]
ASF GitHub Bot commented on MNG-7848:
-
kun-lu20 commented on code in PR #1207:
URL: https://github.com/apache/maven/pull/1207#discussion_r1274985494
##
Jenkinsfile.s390x:
##
@@ -0,0 +1,173 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+properties([buildDiscarder(logRotator(artifactNumToKeepStr: '5', numToKeepStr:
env.BRANCH_NAME=='master'?'5':'1'))])
+
+def buildOs = 'linux'
Review Comment:
I think `linux` is ok in here, since we specified `s390x` in node
declarations:
```groovy
node('s390x') {
```
> Add s390x pipeline to Jenkins CI
>
>
> Key: MNG-7848
> URL: https://issues.apache.org/jira/browse/MNG-7848
> Project: Maven
> Issue Type: New Feature
> Components: Bootstrap Build, Integration Tests
>Reporter: Kun Lu
>Priority: Major
> Labels: pull-request-available
>
> Apache INFRA team has installed necessary JDK flavours on all s390x nodes
> (Please check issue
> [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d
> like to add the s390x pipeline to Jenkins CI by raising a PR to add `
> Jenkinsfile.s390x` to the Maven code base.
> Can anyone from Maven team help us review the PR and create the s390x
> pipeline on Jenkins? Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] kun-lu20 commented on a diff in pull request #1207: [MNG-7848] Add s390x pipeline to Jenkins CI
kun-lu20 commented on code in PR #1207:
URL: https://github.com/apache/maven/pull/1207#discussion_r1274985494
##
Jenkinsfile.s390x:
##
@@ -0,0 +1,173 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+properties([buildDiscarder(logRotator(artifactNumToKeepStr: '5', numToKeepStr:
env.BRANCH_NAME=='master'?'5':'1'))])
+
+def buildOs = 'linux'
Review Comment:
I think `linux` is ok in here, since we specified `s390x` in node
declarations:
```groovy
node('s390x') {
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747514#comment-17747514 ] ASF GitHub Bot commented on MNG-7848: - slachiewicz commented on code in PR #1207: URL: https://github.com/apache/maven/pull/1207#discussion_r1274575573 ## Jenkinsfile.s390x: ## @@ -0,0 +1,173 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +properties([buildDiscarder(logRotator(artifactNumToKeepStr: '5', numToKeepStr: env.BRANCH_NAME=='master'?'5':'1'))]) + +def buildOs = 'linux' Review Comment: Linux or maybe s390? > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] slachiewicz commented on a diff in pull request #1207: [MNG-7848] Add s390x pipeline to Jenkins CI
slachiewicz commented on code in PR #1207: URL: https://github.com/apache/maven/pull/1207#discussion_r1274575573 ## Jenkinsfile.s390x: ## @@ -0,0 +1,173 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +properties([buildDiscarder(logRotator(artifactNumToKeepStr: '5', numToKeepStr: env.BRANCH_NAME=='master'?'5':'1'))]) + +def buildOs = 'linux' Review Comment: Linux or maybe s390? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747502#comment-17747502 ] ASF GitHub Bot commented on MNG-7848: - kun-lu20 commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1651779132 Hi @slachiewicz , I found that in the implementation of function `mvnFromVersion()` [here](https://github.com/apache/maven-jenkins-env/blob/61ee8f931e8ed3bf231970d4da21b0d62e58fcc2/vars/jenkinsEnv.groovy#L74-L75), tool `maven_3_latest` will be used for 3.8.x, so for now actually maven-3.9.3 is being used for build and test, both on amd64 and s390x Jenkinsfile. Please let me know if I missed anything, thanks! > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[
https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747493#comment-17747493
]
ASF GitHub Bot commented on MNG-7848:
-
kun-lu20 commented on PR #1207:
URL: https://github.com/apache/maven/pull/1207#issuecomment-1651732478
Hi @slachiewicz ,
Thanks for your feedback! I checked [amd64
Jenkinsfile](https://github.com/apache/maven/blob/master/Jenkinsfile) and it
only uses Maven 3.8.x to build and test, the same as what we did in this PR for
s390x Jenkinsfile:
```groovy
def buildMvn = '3.8.x'
...
def runITsMvn = '3.8.x'
```
Do you mean I should change the following line to maven-3.9.x only?
```groovy
if (env.BRANCH_NAME in ['master', 'maven-3.8.x', 'maven-3.9.x']){
```
Thank you very much!
> Add s390x pipeline to Jenkins CI
>
>
> Key: MNG-7848
> URL: https://issues.apache.org/jira/browse/MNG-7848
> Project: Maven
> Issue Type: New Feature
> Components: Bootstrap Build, Integration Tests
>Reporter: Kun Lu
>Priority: Major
> Labels: pull-request-available
>
> Apache INFRA team has installed necessary JDK flavours on all s390x nodes
> (Please check issue
> [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d
> like to add the s390x pipeline to Jenkins CI by raising a PR to add `
> Jenkinsfile.s390x` to the Maven code base.
> Can anyone from Maven team help us review the PR and create the s390x
> pipeline on Jenkins? Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] kun-lu20 commented on pull request #1207: [MNG-7848] Add s390x pipeline to Jenkins CI
kun-lu20 commented on PR #1207:
URL: https://github.com/apache/maven/pull/1207#issuecomment-1651732478
Hi @slachiewicz ,
Thanks for your feedback! I checked [amd64
Jenkinsfile](https://github.com/apache/maven/blob/master/Jenkinsfile) and it
only uses Maven 3.8.x to build and test, the same as what we did in this PR for
s390x Jenkinsfile:
```groovy
def buildMvn = '3.8.x'
...
def runITsMvn = '3.8.x'
```
Do you mean I should change the following line to maven-3.9.x only?
```groovy
if (env.BRANCH_NAME in ['master', 'maven-3.8.x', 'maven-3.9.x']){
```
Thank you very much!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747492#comment-17747492 ] ASF GitHub Bot commented on MRESOLVER-387: -- cstamas opened a new pull request, #319: URL: https://github.com/apache/maven-resolver/pull/319 Added a new module, as to complete RepositorySystem instance, one needs some of Maven dependencies as well. --- https://issues.apache.org/jira/browse/MRESOLVER-387 > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #319: [MRESOLVER-387] New RepositorySystem supplier
cstamas opened a new pull request, #319: URL: https://github.com/apache/maven-resolver/pull/319 Added a new module, as to complete RepositorySystem instance, one needs some of Maven dependencies as well. --- https://issues.apache.org/jira/browse/MRESOLVER-387 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7820) Remove dependency on plexus-utils
[
https://issues.apache.org/jira/browse/MNG-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747452#comment-17747452
]
ASF GitHub Bot commented on MNG-7820:
-
elharo commented on code in PR #1208:
URL: https://github.com/apache/maven/pull/1208#discussion_r1274768736
##
maven-compat/src/main/java/org/apache/maven/profiles/activation/OperatingSystemProfileActivator.java:
##
@@ -18,17 +18,48 @@
*/
package org.apache.maven.profiles.activation;
+import java.util.Locale;
+
import org.apache.maven.model.Activation;
import org.apache.maven.model.ActivationOS;
import org.apache.maven.model.Profile;
-import org.codehaus.plexus.util.Os;
/**
* OperatingSystemProfileActivator
*/
@Deprecated
public class OperatingSystemProfileActivator implements ProfileActivator {
+public static final String FAMILY_DOS = "dos";
Review Comment:
why are these public? especially in a deprecated class?
##
maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java:
##
@@ -465,6 +469,28 @@ public void getRemoteFile(
}
}
+private void copyFile(File source, File destination) throws IOException {
Review Comment:
These sorts of methods are very tricky with lots of inobvious, platform
dependent edge cases that are hard to get right. I'd be much more comfortable
if we could use a single method from commons-io like FileUtils.copyFile
##
maven-core/src/main/java/org/apache/maven/utils/introspection/ReflectionValueExtractor.java:
##
@@ -0,0 +1,325 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.utils.introspection;
+
+import java.lang.ref.WeakReference;
+import java.lang.reflect.Array;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.util.List;
+import java.util.Map;
+import java.util.WeakHashMap;
+
+/**
+ *
+ * Using simple dotted expressions to extract the values from an Object
instance, For example we might want to extract a
+ * value like: project.build.sourceDirectory
+ *
+ *
+ * The implementation supports indexed, nested and mapped properties similar
to the JSP way.
+ *
+ *
+ * @author mailto:ja...@maven.org;>Jason van Zyl
+ * @author mailto:vincent.sive...@gmail.com;>Vincent Siveton
+ *
+ * @see http://struts.apache.org/1.x/struts-taglib/indexedprops.html;>http://struts.apache.org/1.x/struts-taglib/indexedprops.html
+ */
+public class ReflectionValueExtractor {
Review Comment:
non-public if possible
##
maven-core/src/main/java/org/apache/maven/utils/dag/Vertex.java:
##
@@ -0,0 +1,151 @@
+/*
Review Comment:
These classes seem to have simply been copied over from plexus. I'm no sure
you can simply remove copyright like that but IANAL
##
maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java:
##
@@ -465,6 +469,28 @@ public void getRemoteFile(
}
}
+private void copyFile(File source, File destination) throws IOException {
+String message;
Review Comment:
declare whrere used, and don't reuse for two different messages
##
maven-core/src/main/java/org/apache/maven/utils/dag/CycleDetector.java:
##
@@ -0,0 +1,136 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.utils.dag;
+
[GitHub] [maven] elharo commented on a diff in pull request #1208: [MNG-7820] Remove dependency on plexus-utils
elharo commented on code in PR #1208:
URL: https://github.com/apache/maven/pull/1208#discussion_r1274768736
##
maven-compat/src/main/java/org/apache/maven/profiles/activation/OperatingSystemProfileActivator.java:
##
@@ -18,17 +18,48 @@
*/
package org.apache.maven.profiles.activation;
+import java.util.Locale;
+
import org.apache.maven.model.Activation;
import org.apache.maven.model.ActivationOS;
import org.apache.maven.model.Profile;
-import org.codehaus.plexus.util.Os;
/**
* OperatingSystemProfileActivator
*/
@Deprecated
public class OperatingSystemProfileActivator implements ProfileActivator {
+public static final String FAMILY_DOS = "dos";
Review Comment:
why are these public? especially in a deprecated class?
##
maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java:
##
@@ -465,6 +469,28 @@ public void getRemoteFile(
}
}
+private void copyFile(File source, File destination) throws IOException {
Review Comment:
These sorts of methods are very tricky with lots of inobvious, platform
dependent edge cases that are hard to get right. I'd be much more comfortable
if we could use a single method from commons-io like FileUtils.copyFile
##
maven-core/src/main/java/org/apache/maven/utils/introspection/ReflectionValueExtractor.java:
##
@@ -0,0 +1,325 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.utils.introspection;
+
+import java.lang.ref.WeakReference;
+import java.lang.reflect.Array;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.util.List;
+import java.util.Map;
+import java.util.WeakHashMap;
+
+/**
+ *
+ * Using simple dotted expressions to extract the values from an Object
instance, For example we might want to extract a
+ * value like: project.build.sourceDirectory
+ *
+ *
+ * The implementation supports indexed, nested and mapped properties similar
to the JSP way.
+ *
+ *
+ * @author mailto:ja...@maven.org;>Jason van Zyl
+ * @author mailto:vincent.sive...@gmail.com;>Vincent Siveton
+ *
+ * @see http://struts.apache.org/1.x/struts-taglib/indexedprops.html;>http://struts.apache.org/1.x/struts-taglib/indexedprops.html
+ */
+public class ReflectionValueExtractor {
Review Comment:
non-public if possible
##
maven-core/src/main/java/org/apache/maven/utils/dag/Vertex.java:
##
@@ -0,0 +1,151 @@
+/*
Review Comment:
These classes seem to have simply been copied over from plexus. I'm no sure
you can simply remove copyright like that but IANAL
##
maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java:
##
@@ -465,6 +469,28 @@ public void getRemoteFile(
}
}
+private void copyFile(File source, File destination) throws IOException {
+String message;
Review Comment:
declare whrere used, and don't reuse for two different messages
##
maven-core/src/main/java/org/apache/maven/utils/dag/CycleDetector.java:
##
@@ -0,0 +1,136 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.utils.dag;
+
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.LinkedList;
+import java.util.List;
+import java.util.Map;
+
+/**
+ * @author Michal Maczka
+ *
+ */
+public class CycleDetector {
+
+private static final
[GitHub] [maven-site] cstamas opened a new pull request, #442: Maven 3.9.4 release notes
cstamas opened a new pull request, #442: URL: https://github.com/apache/maven-site/pull/442 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7850) Artifact Resolver config is ignored
[
https://issues.apache.org/jira/browse/MNG-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MNG-7850.
Resolution: Information Provided
> Artifact Resolver config is ignored
> ---
>
> Key: MNG-7850
> URL: https://issues.apache.org/jira/browse/MNG-7850
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General
>Affects Versions: 3.9.3
>Reporter: Cosimo Damiano Prete
>Priority: Major
>
> Hi.
> I've tried to follow the documentation at
> [https://maven.apache.org/guides/mini/guide-resolver-transport.html] to
> migrate from Wagon to the new HTTP Artifact Resolver, but it's not clear to
> me where and how I should set the new
> {{aether.connector.http.preemptiveAuth}} property in order to make the
> resolver use it properly, like it was with Wagon.
> My (template of the) {{settings.xml}} is as follows:
> {code:xml}
>
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
> ${env.CI_PROJECT_DIR}/{{ template
> "maven-m2-folder-name" }}/repository
>
>
> artifactory.release.credentials
> {{ template "mandatory-image-credentials-username"
> .Values.imageCredentials.username }}
> {{ template "mandatory-image-credentials-password"
> .Values.imageCredentials.password }}
>
>
> true
>
>
>
> true
>
>
>
>
>
> artifactory.snapshot.credentials
> {{ template "mandatory-image-credentials-username"
> .Values.imageCredentials.username }}
> {{ template "mandatory-image-credentials-password"
> .Values.imageCredentials.password }}
>
>
> true
>
>
>
> true
>
>
>
>
>
>
>
> maven-repository
>
> true
>
>
>
> artifactory.release.credentials
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent
>
> never
> fail
>
>
> false
>
>
>
> artifactory.snapshot.credentials
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent-snapshot
>
> false
>
>
>
>
>
>
>
> artifactory.release.credentials
> Artifactory mirror repository
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent
>
> *,!artifactory.release.credentials,!artifactory.snapshot.credentials
>
>
>
> {code}
> but the property seems to be ignored, causing Maven to complain that's not
> able to find my artifacts.
> As (hopefully temporary) solution, I'm setting the {{MAVEN_ARGS}} environment
> variable with the value {{{}-Daether.connector.http.preemptiveAuth=true{}}}.
> The weird thing is that, in {{{}DEBUG{}}}, I can see that somehow the
> property is applied and the credentials are picked up
> {code:bash}
> [DEBUG] Using transporter HttpTransporter with priority 5.0 for
> https:///artifactory//
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https:///artifactory// with
> username=, password=*** {code}
> but, somehow, only once while when applying
> {{-Daether.connector.http.preemptiveAuth=true}} I can see the same logs
> multiple times (maybe once for every artifact).
> Can you please provide some guidance/help on this?
> I would also suggest to add to the documentation a/some example/s on how the
> migration should be really done.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7851) Error message when modelVersion is 4.0 is confusing
[
https://issues.apache.org/jira/browse/MNG-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747423#comment-17747423
]
ASF GitHub Bot commented on MNG-7851:
-
michael-o commented on PR #1210:
URL: https://github.com/apache/maven/pull/1210#issuecomment-1651384058
Just checked, the schema does not enforce the model version...weird. I'd say
that it should be fixed literal `4.0.0`. For me, this is similar to an XML
namespace, if you change a single char then you change the entire namespace.
@gnodet @cstamas @hboutemy WDYT?
> Error message when modelVersion is 4.0 is confusing
> ---
>
> Key: MNG-7851
> URL: https://issues.apache.org/jira/browse/MNG-7851
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.3
>Reporter: Craig
>Priority: Minor
>
> When a pom with modelVersion 4.0 is referenced, such as this one:
> {code:xml}
>
> 4.0
> foo
> bar
> 0.1
>
> {code}
> The error message is:
> {{'modelVersion' of '4.0' is newer than the versions supported by this
> version of Maven: [4.0.0]. Building this project requires a newer version of
> Maven.}}
>
> That's misleading.
> A better error message would be:
> {{'modelVersion' must be one of [4.0.0] but is '4.0'.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #1210: [MNG-7851] Improve error message when modelVersion is 4.0
michael-o commented on PR #1210: URL: https://github.com/apache/maven/pull/1210#issuecomment-1651384058 Just checked, the schema does not enforce the model version...weird. I'd say that it should be fixed literal `4.0.0`. For me, this is similar to an XML namespace, if you change a single char then you change the entire namespace. @gnodet @cstamas @hboutemy WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7850) Artifact Resolver config is ignored
[
https://issues.apache.org/jira/browse/MNG-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747420#comment-17747420
]
Cosimo Damiano Prete commented on MNG-7850:
---
Yes. Thank you.
> Artifact Resolver config is ignored
> ---
>
> Key: MNG-7850
> URL: https://issues.apache.org/jira/browse/MNG-7850
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General
>Affects Versions: 3.9.3
>Reporter: Cosimo Damiano Prete
>Priority: Major
>
> Hi.
> I've tried to follow the documentation at
> [https://maven.apache.org/guides/mini/guide-resolver-transport.html] to
> migrate from Wagon to the new HTTP Artifact Resolver, but it's not clear to
> me where and how I should set the new
> {{aether.connector.http.preemptiveAuth}} property in order to make the
> resolver use it properly, like it was with Wagon.
> My (template of the) {{settings.xml}} is as follows:
> {code:xml}
>
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
> ${env.CI_PROJECT_DIR}/{{ template
> "maven-m2-folder-name" }}/repository
>
>
> artifactory.release.credentials
> {{ template "mandatory-image-credentials-username"
> .Values.imageCredentials.username }}
> {{ template "mandatory-image-credentials-password"
> .Values.imageCredentials.password }}
>
>
> true
>
>
>
> true
>
>
>
>
>
> artifactory.snapshot.credentials
> {{ template "mandatory-image-credentials-username"
> .Values.imageCredentials.username }}
> {{ template "mandatory-image-credentials-password"
> .Values.imageCredentials.password }}
>
>
> true
>
>
>
> true
>
>
>
>
>
>
>
> maven-repository
>
> true
>
>
>
> artifactory.release.credentials
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent
>
> never
> fail
>
>
> false
>
>
>
> artifactory.snapshot.credentials
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent-snapshot
>
> false
>
>
>
>
>
>
>
> artifactory.release.credentials
> Artifactory mirror repository
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent
>
> *,!artifactory.release.credentials,!artifactory.snapshot.credentials
>
>
>
> {code}
> but the property seems to be ignored, causing Maven to complain that's not
> able to find my artifacts.
> As (hopefully temporary) solution, I'm setting the {{MAVEN_ARGS}} environment
> variable with the value {{{}-Daether.connector.http.preemptiveAuth=true{}}}.
> The weird thing is that, in {{{}DEBUG{}}}, I can see that somehow the
> property is applied and the credentials are picked up
> {code:bash}
> [DEBUG] Using transporter HttpTransporter with priority 5.0 for
> https:///artifactory//
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https:///artifactory// with
> username=, password=*** {code}
> but, somehow, only once while when applying
> {{-Daether.connector.http.preemptiveAuth=true}} I can see the same logs
> multiple times (maybe once for every artifact).
> Can you please provide some guidance/help on this?
> I would also suggest to add to the documentation a/some example/s on how the
> migration should be really done.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7850) Artifact Resolver config is ignored
[
https://issues.apache.org/jira/browse/MNG-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747419#comment-17747419
]
Slawomir Jaranowski commented on MNG-7850:
--
{quote}
Edit2: the issue was on my side (wrong repository ID)
{quote}
And documentation was update, so I think we can close as information provided
> Artifact Resolver config is ignored
> ---
>
> Key: MNG-7850
> URL: https://issues.apache.org/jira/browse/MNG-7850
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General
>Affects Versions: 3.9.3
>Reporter: Cosimo Damiano Prete
>Priority: Major
>
> Hi.
> I've tried to follow the documentation at
> [https://maven.apache.org/guides/mini/guide-resolver-transport.html] to
> migrate from Wagon to the new HTTP Artifact Resolver, but it's not clear to
> me where and how I should set the new
> {{aether.connector.http.preemptiveAuth}} property in order to make the
> resolver use it properly, like it was with Wagon.
> My (template of the) {{settings.xml}} is as follows:
> {code:xml}
>
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
> ${env.CI_PROJECT_DIR}/{{ template
> "maven-m2-folder-name" }}/repository
>
>
> artifactory.release.credentials
> {{ template "mandatory-image-credentials-username"
> .Values.imageCredentials.username }}
> {{ template "mandatory-image-credentials-password"
> .Values.imageCredentials.password }}
>
>
> true
>
>
>
> true
>
>
>
>
>
> artifactory.snapshot.credentials
> {{ template "mandatory-image-credentials-username"
> .Values.imageCredentials.username }}
> {{ template "mandatory-image-credentials-password"
> .Values.imageCredentials.password }}
>
>
> true
>
>
>
> true
>
>
>
>
>
>
>
> maven-repository
>
> true
>
>
>
> artifactory.release.credentials
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent
>
> never
> fail
>
>
> false
>
>
>
> artifactory.snapshot.credentials
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent-snapshot
>
> false
>
>
>
>
>
>
>
> artifactory.release.credentials
> Artifactory mirror repository
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent
>
> *,!artifactory.release.credentials,!artifactory.snapshot.credentials
>
>
>
> {code}
> but the property seems to be ignored, causing Maven to complain that's not
> able to find my artifacts.
> As (hopefully temporary) solution, I'm setting the {{MAVEN_ARGS}} environment
> variable with the value {{{}-Daether.connector.http.preemptiveAuth=true{}}}.
> The weird thing is that, in {{{}DEBUG{}}}, I can see that somehow the
> property is applied and the credentials are picked up
> {code:bash}
> [DEBUG] Using transporter HttpTransporter with priority 5.0 for
> https:///artifactory//
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https:///artifactory// with
> username=, password=*** {code}
> but, somehow, only once while when applying
> {{-Daether.connector.http.preemptiveAuth=true}} I can see the same logs
> multiple times (maybe once for every artifact).
> Can you please provide some guidance/help on this?
> I would also suggest to add to the documentation a/some example/s on how the
> migration should be really done.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-275) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MJAR-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747413#comment-17747413
]
Michael Osipov commented on MJAR-275:
-
I'd pursue a JDK fix first.
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MJAR-275
> URL: https://issues.apache.org/jira/browse/MJAR-275
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Assignee: Slawomir Jaranowski
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: MCOMPILER-439.zip, Screenshot 2020-10-25 at 2.35.59
> PM.png
>
>
> Setting {{project.build.outputTimestamp}} to a fixed value allows creating
> reproducible builds per this guide:
> [https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> |https://maven.apache.org/guides/mini/guide-reproducible-builds.html]However,
> if one adds a module-info file to the project, reproducible builds break.
> This is caused by module-info.class using the latest timestamp and not
> {{project.build.outputTimestamp}}. I was able to identify the problem using
> diffoscope: [https://diffoscope.org/.|https://diffoscope.org/] With it I
> determined the timestamp across 2 builds was constant for all but the
> module-info.class:
>
> {code:java}
> -rw 2.0 fat 862 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrder.class
> │ -rw 2.0 fat 1113 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrderBuilder.class
> │ -rw 2.0 fat 2285 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.xml
> │ -rw 2.0 fat 74 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.properties
> │ --rw 2.0 fat 557 bl defN 20-Oct-25 12:39 module-info.class
> │ +-rw 2.0 fat 557 bl defN 20-Oct-25 12:41 module-info.class
> {code}
>
> Note the + and - which are diffoscope's way of indicating the difference
> between the .jar files. Here the {{project.build.outputTimestamp}} is on 17
> October. As shown, module-info has a "rebellious" timestamp.
>
> *EDIT:*
> Example project to reproduce the bug:
> [https://github.com/A248/MJAR-275|https://github.com/A248/MCOMPILER-439]
> (Renamed from [https://github.com/A248/MCOMPILER-439])
> Source code is also provided as an attachment below
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MSITE-971) Site generation not resolving git.commit.time
[
https://issues.apache.org/jira/browse/MSITE-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSITE-971:
Assignee: Michael Osipov
> Site generation not resolving git.commit.time
> -
>
> Key: MSITE-971
> URL: https://issues.apache.org/jira/browse/MSITE-971
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: property interpolation
>Affects Versions: 4.0.0-M9
> Environment: Windows 10 and FreeBSD
>Reporter: Brad Larrick
>Assignee: Michael Osipov
>Priority: Major
>
> I'm using git-commit-id-maven-plugin to set project.build.outputTimestamp as
> suggested in the Maven Guide Configuring for Reproducible Builds. I've
> included the plugin in my pom and including the following property definition:
>
> {code:java}
> ${git.commit.time}{code}
>
> When I generate the site, the plugin fails with the message:
> {{site failed: Invalid project.build.outputTimestamp value
> '${git.commit.time}}}
> This configuration works properly in the maven-jar-plugin, so I did some
> investigation. The jar plugin is getting the outputTimestamp as a mojo
> parameter:
>
> {code:java}
> @Parameter( defaultValue = "${project.build.outputTimestamp}" )
> private String outputTimestamp;
> {code}
> This works properly, with outputTimestamp set to the last commit time.
> In the site-plugin code, the outputTimestamp is being pulled from the project
> properties:
> {code:java}
> String outputTimestamp =
> p.getProperties().getProperty("project.build.outputTimestamp");{code}
> In the case the property hasn't been resolved and the returned string is
> ${git.commit.time}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7850) Artifact Resolver config is ignored
[
https://issues.apache.org/jira/browse/MNG-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747405#comment-17747405
]
ASF GitHub Bot commented on MNG-7850:
-
slawekjaranowski merged PR #441:
URL: https://github.com/apache/maven-site/pull/441
> Artifact Resolver config is ignored
> ---
>
> Key: MNG-7850
> URL: https://issues.apache.org/jira/browse/MNG-7850
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General
>Affects Versions: 3.9.3
>Reporter: Cosimo Damiano Prete
>Priority: Major
>
> Hi.
> I've tried to follow the documentation at
> [https://maven.apache.org/guides/mini/guide-resolver-transport.html] to
> migrate from Wagon to the new HTTP Artifact Resolver, but it's not clear to
> me where and how I should set the new
> {{aether.connector.http.preemptiveAuth}} property in order to make the
> resolver use it properly, like it was with Wagon.
> My (template of the) {{settings.xml}} is as follows:
> {code:xml}
>
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
> ${env.CI_PROJECT_DIR}/{{ template
> "maven-m2-folder-name" }}/repository
>
>
> artifactory.release.credentials
> {{ template "mandatory-image-credentials-username"
> .Values.imageCredentials.username }}
> {{ template "mandatory-image-credentials-password"
> .Values.imageCredentials.password }}
>
>
> true
>
>
>
> true
>
>
>
>
>
> artifactory.snapshot.credentials
> {{ template "mandatory-image-credentials-username"
> .Values.imageCredentials.username }}
> {{ template "mandatory-image-credentials-password"
> .Values.imageCredentials.password }}
>
>
> true
>
>
>
> true
>
>
>
>
>
>
>
> maven-repository
>
> true
>
>
>
> artifactory.release.credentials
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent
>
> never
> fail
>
>
> false
>
>
>
> artifactory.snapshot.credentials
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent-snapshot
>
> false
>
>
>
>
>
>
>
> artifactory.release.credentials
> Artifactory mirror repository
> {{ template "artifactory-base-url"
> .Values.imageCredentials.registry }}/artifactory/torrent
>
> *,!artifactory.release.credentials,!artifactory.snapshot.credentials
>
>
>
> {code}
> but the property seems to be ignored, causing Maven to complain that's not
> able to find my artifacts.
> As (hopefully temporary) solution, I'm setting the {{MAVEN_ARGS}} environment
> variable with the value {{{}-Daether.connector.http.preemptiveAuth=true{}}}.
> The weird thing is that, in {{{}DEBUG{}}}, I can see that somehow the
> property is applied and the credentials are picked up
> {code:bash}
> [DEBUG] Using transporter HttpTransporter with priority 5.0 for
> https:///artifactory//
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https:///artifactory// with
> username=, password=*** {code}
> but, somehow, only once while when applying
> {{-Daether.connector.http.preemptiveAuth=true}} I can see the same logs
> multiple times (maybe once for every artifact).
> Can you please provide some guidance/help on this?
> I would also suggest to add to the documentation a/some example/s on how the
> migration should be really done.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] slawekjaranowski merged pull request #441: [MNG-7850] Add example for low-level resolver configuration
slawekjaranowski merged PR #441: URL: https://github.com/apache/maven-site/pull/441 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (ARCHETYPE-647) additional new lines in generated pom.xml
[ https://issues.apache.org/jira/browse/ARCHETYPE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747383#comment-17747383 ] Filip Stachowiak commented on ARCHETYPE-647: 8, 11 and 17. > additional new lines in generated pom.xml > - > > Key: ARCHETYPE-647 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-647 > Project: Maven Archetype > Issue Type: Bug >Affects Versions: 3.2.1 >Reporter: Filip Stachowiak >Priority: Minor > > When generating project from this minimal archetype: > [https://github.com/fistach/maven-archetype-issue] > the top-level pom.xml contains additional new lines. > > Tested on Java 8, 11 and 17. > > When the section is removed from the archetype-metadata.xml, > everything is ok. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747378#comment-17747378 ] ASF GitHub Bot commented on MNG-7848: - slachiewicz commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1651219837 Please run tests only on Maven 3.9 - to effectively use resources > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-32) Do not print exception when probing builds in remote repo
[
https://issues.apache.org/jira/browse/MBUILDCACHE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747376#comment-17747376
]
ASF GitHub Bot commented on MBUILDCACHE-32:
---
alexthomasmc commented on code in PR #33:
URL:
https://github.com/apache/maven-build-cache-extension/pull/33#discussion_r1274550737
##
src/main/java/org/apache/maven/buildcache/RemoteCacheRepositoryImpl.java:
##
@@ -165,9 +166,28 @@ public Optional getResourceContent( String url )
throws IOException
transporter.get( task );
return Optional.of( task.getDataBytes() );
}
+catch ( ResourceDoesNotExistException e )
+{
+if ( LOGGER.isDebugEnabled() )
+{
+LOGGER.debug( "Cache item not found: {}", getFullUrl( url ), e
);
+}
+else
+{
+LOGGER.info( "Cache item not found: {}", getFullUrl( url ) );
+}
+return Optional.empty();
+}
catch ( Exception e )
{
-LOGGER.info( "Cannot download {}", getFullUrl( url ), e );
+if ( LOGGER.isDebugEnabled() )
+{
+LOGGER.debug( "Cannot download cache item {}", getFullUrl( url
), e );
+}
+else
+{
+LOGGER.error( "Cannot download cache item {}: {}", getFullUrl(
url ), e );
+}
Review Comment:
The cache miss exception is caught just before this, so by the time we get
here there's a bigger problem. Agree with your policy on this - I think that's
the intent of the current logic, it's just the logging that's the issue.
> Do not print exception when probing builds in remote repo
> -
>
> Key: MBUILDCACHE-32
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-32
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Alexander Ashitkin
>Priority: Major
> Labels: pull-request-available
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When cache engine tries to discover existing cache by checksum, it sends get
> request.
> This request is normally getting 404s, because cache is not guaranteed to
> exist.
> It's a normal situation and exception should not be printed in such case as
> it meaninglessly pollutes logs:
> {code:java}
> org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at
> https://my-cache/.../buildinfo.xml, status: 404 Not Found
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1191)
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewerToStream
> (StreamWagon.java:226)
> at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:533)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:425)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:400)
> at
> org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent
> (RemoteCacheRepositoryImpl.java:165)
> at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild
> (RemoteCacheRepositoryImpl.java:114)
> at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild
> (LocalCacheRepositoryImpl.java:183)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:212)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:179)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:114)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:179)
> {code}
> {{Need to create method similar to
> RemoteCacheRepositoryImpl#getResourceContent, but }}{{getResourceContentQuiet
> and use it when probing buildinfo.xml. the method should not log exceptions}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-build-cache-extension] alexthomasmc commented on a diff in pull request #33: [MBUILDCACHE-32] Do not print exception when probing builds
alexthomasmc commented on code in PR #33:
URL:
https://github.com/apache/maven-build-cache-extension/pull/33#discussion_r1274550737
##
src/main/java/org/apache/maven/buildcache/RemoteCacheRepositoryImpl.java:
##
@@ -165,9 +166,28 @@ public Optional getResourceContent( String url )
throws IOException
transporter.get( task );
return Optional.of( task.getDataBytes() );
}
+catch ( ResourceDoesNotExistException e )
+{
+if ( LOGGER.isDebugEnabled() )
+{
+LOGGER.debug( "Cache item not found: {}", getFullUrl( url ), e
);
+}
+else
+{
+LOGGER.info( "Cache item not found: {}", getFullUrl( url ) );
+}
+return Optional.empty();
+}
catch ( Exception e )
{
-LOGGER.info( "Cannot download {}", getFullUrl( url ), e );
+if ( LOGGER.isDebugEnabled() )
+{
+LOGGER.debug( "Cannot download cache item {}", getFullUrl( url
), e );
+}
+else
+{
+LOGGER.error( "Cannot download cache item {}: {}", getFullUrl(
url ), e );
+}
Review Comment:
The cache miss exception is caught just before this, so by the time we get
here there's a bigger problem. Agree with your policy on this - I think that's
the intent of the current logic, it's just the logging that's the issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Closed] (MPLUGIN-476) Cannot invoke "com.thoughtworks.qdox.model.JavaField.getName()" because "field" is null
[
https://issues.apache.org/jira/browse/MPLUGIN-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MPLUGIN-476.
---
Resolution: Information Provided
> Cannot invoke "com.thoughtworks.qdox.model.JavaField.getName()" because
> "field" is null
> ---
>
> Key: MPLUGIN-476
> URL: https://issues.apache.org/jira/browse/MPLUGIN-476
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: Plugin Plugin
>Affects Versions: 3.9.0
>Reporter: Ernst Reissner
>Priority: Major
>
> I write a plugin (https://github.com/Reissner/latex-maven-plugin)
> and `mvn clean deploy` results in following message:
> ```
> [INFO] --- plugin:3.9.0:descriptor (default-descriptor) @ latex-maven-plugin
> ---
> [INFO] Using 'UTF-8' encoding to read mojo source files.
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 14.056 s
> [INFO] Finished at: 2023-06-22T09:29:29+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor
> (default-descriptor) on project latex-maven-plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor failed: Cannot
> invoke "com.thoughtworks.qdox.model.JavaField.getName()" because "field" is
> null -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> ```
> After long search (1 night) I found the following 'reason':
> ```
> package eu.simuline.m2latex.core;
> public enum Target {
> txt() {
> private final String TXT_OUTPUT_FILES = "^T$T\\.txt$";
> // may throw BuildFailureException TEX01
> public void processSource(LatexProcessor latexProcessor,
> LatexMainDesc desc) throws
> BuildFailureException {
> latexProcessor.processLatex2txt(desc);
> }
> public String getPatternOutputFiles(Settings settings) {
> return "^T$T\\.txt$";
> }
> }, ...;
> ...
> }
> ```
> Removing the line
> ```
> private final String TXT_OUTPUT_FILES = "^T$T\\.txt$";
> ```
> 'resolves' the problem.
> I feel this could indicate not just a bug but a conceptual flaw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-476) Cannot invoke "com.thoughtworks.qdox.model.JavaField.getName()" because "field" is null
[
https://issues.apache.org/jira/browse/MPLUGIN-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747322#comment-17747322
]
Slawomir Jaranowski commented on MPLUGIN-476:
-
It is a bug in {{qdox}} library, please report at:
https://github.com/paul-hammant/qdox
> Cannot invoke "com.thoughtworks.qdox.model.JavaField.getName()" because
> "field" is null
> ---
>
> Key: MPLUGIN-476
> URL: https://issues.apache.org/jira/browse/MPLUGIN-476
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: Plugin Plugin
>Affects Versions: 3.9.0
>Reporter: Ernst Reissner
>Priority: Major
>
> I write a plugin (https://github.com/Reissner/latex-maven-plugin)
> and `mvn clean deploy` results in following message:
> ```
> [INFO] --- plugin:3.9.0:descriptor (default-descriptor) @ latex-maven-plugin
> ---
> [INFO] Using 'UTF-8' encoding to read mojo source files.
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 14.056 s
> [INFO] Finished at: 2023-06-22T09:29:29+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor
> (default-descriptor) on project latex-maven-plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor failed: Cannot
> invoke "com.thoughtworks.qdox.model.JavaField.getName()" because "field" is
> null -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> ```
> After long search (1 night) I found the following 'reason':
> ```
> package eu.simuline.m2latex.core;
> public enum Target {
> txt() {
> private final String TXT_OUTPUT_FILES = "^T$T\\.txt$";
> // may throw BuildFailureException TEX01
> public void processSource(LatexProcessor latexProcessor,
> LatexMainDesc desc) throws
> BuildFailureException {
> latexProcessor.processLatex2txt(desc);
> }
> public String getPatternOutputFiles(Settings settings) {
> return "^T$T\\.txt$";
> }
> }, ...;
> ...
> }
> ```
> Removing the line
> ```
> private final String TXT_OUTPUT_FILES = "^T$T\\.txt$";
> ```
> 'resolves' the problem.
> I feel this could indicate not just a bug but a conceptual flaw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
