[jira] [Commented] (SUREFIRE-1917) Surefire plug-in level dependency doesn't work
[ https://issues.apache.org/jira/browse/SUREFIRE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748692#comment-17748692 ] Marco Brandizi commented on SUREFIRE-1917: -- Hi all, just to let you know this still doesn't work with surefire 3.1.2 > Surefire plug-in level dependency doesn't work > -- > > Key: SUREFIRE-1917 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1917 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 3.0.0-M5 > Environment: 18:41:33 [root@MAC10143-ROTH tmp]# mvn -v > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/local/Cellar/maven/3.6.3/libexec > Java version: 11.0.10, vendor: AdoptOpenJDK, runtime: > /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > 18:48:39 [root@MAC10143-ROTH tmp]# >Reporter: Marco Brandizi >Priority: Major > Attachments: junit-deptest.zip > > > I've been using a Junit 4.x > [listener|https://github.com/marco-brandizi/jutils/blob/master/jutils/src/main/java/uk/ac/ebi/utils/test/junit/TestOutputDecorator.java] > for years, to wrap every test method run with nice header/trailer > decorations. > I've been doing this by adding the dependency to the listener class in the > surefire's section and then using the property listener. > I've just discovered that this doesn't work anymore with 3.0.0-M5 version: it > says that the listener's ClassNotFoundException for the listener class. > You can verify this with the attached simple project. > Using it, I've tried several older versions until I found that the latest > working is 2.19.1, the 2.20.1 raises a NullPointerEx and I didn't get exactly > where (see the .out in the attachment). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17748682#comment-17748682
]
Slawomir Jaranowski commented on MNG-7852:
--
[~vladimirsitnikov] There is no {{proper versions}} nevermind which version we
choose during resolving transitive dependencies, alway we can have an
incompatibilities between two versions.
Enforcer rule can help to detect such situation, and yes you need redeclared
dependencies in dep or depManagement in your project.
Finally tests unit and integration should confirm that your application is
working.
> 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.
> 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.
> 4) see "unexpected" in MNG-5988
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17748677#comment-17748677
]
Vladimir Sitnikov commented on MNG-7852:
[~sjaranowski] , thanks for mentioning dependencyConvergence, however, I do not
think it is a generally recommended solution unless you make the said enforcer
rule enabled by default in all Maven installations.
enforcer does not help users "resolve the conflicts properly". I agree enforcer
might make the dependency resolution issue easier to spot, however, it does not
treat the root cause. The idea behind the current issue is to tune Maven's
behaviour so it resolves proper versions in the first place rather than perform
silent downgrades.
{quote}You need resolve conflicts in your project
{quote}
Could you please clarify what you mean by "resolve conflicts"? Correct me if I
am wrong, but it means "re-declaring all (conflicting?) transitive
dependencies" which is a bad idea because re-declared dependencies might get
out of date (e.g. they might become stale, bad versions, and so on).
> 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.
> 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.
> 4) see "unexpected" in MNG-5988
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17748666#comment-17748666 ] Slawomir Jaranowski commented on MNG-7852: -- Did you consider use https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html Then all artifacts without version conflict will be resolved as is. You need resolve conflicts in your project. There is next rule which can help you: https://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html > 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. > 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. > 4) see "unexpected" in MNG-5988 > 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. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] misaya98 opened a new issue, #872: java.lang.NoClassDefFoundError: Could not initialize class org.mvndaemon.mvnd.nativ.CLibrary
misaya98 opened a new issue, #872: URL: https://github.com/apache/maven-mvnd/issues/872 mvnd version : 0.9.1 jdk version: openjdk version "11.0.16" 2022-07-19 LTS OpenJDK Runtime Environment Zulu11.58+15-CA (build 11.0.16+8-LTS) OpenJDK 64-Bit Server VM Zulu11.58+15-CA (build 11.0.16+8-LTS, mixed mode) error: `PS C:\Users\33156> mvnd java.lang.NoClassDefFoundError: Could not initialize class org.mvndaemon.mvnd.nativ.CLibrary` -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MNG-6357) Dependency order should be nearest first
[
https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748655#comment-17748655
]
Tamas Cservenak edited comment on MNG-6357 at 7/28/23 3:23 PM:
---
The PR with [~suztomo] reproducer:
{noformat}
[cstamas@urnebes main (master %)]$ mvn -V
-Daether.system.resolveDependencies.visitor=preOrder -q exec:exec
-Dexec.executable=echo -Dexec.args="%classpath"
Apache Maven 3.9.5-SNAPSHOT (bf3261cc66fd653ed3457153b2bfbe9bbc7d5d7b)
Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.5-SNAPSHOT
Java version: 17.0.8, vendor: Eclipse Adoptium, runtime:
/home/cstamas/.sdkman/candidates/java/17.0.8-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.4.6-200.fc38.x86_64", arch: "amd64", family:
"unix"
/home/cstamas/tmp/MNG-6357/triangle-linkage-error/main/target/classes:/home/cstamas/.m2/repository-oss/suztomo/artifact1/0.0.1-SNAPSHOT/artifact1-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact4/0.0.1-SNAPSHOT/artifact4-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact2/0.0.1-SNAPSHOT/artifact2-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact5/0.0.1-SNAPSHOT/artifact5-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact3/0.0.1-SNAPSHOT/artifact3-0.0.1-SNAPSHOT.jar
[cstamas@urnebes main (master %)]$ mvn -V
-Daether.system.resolveDependencies.visitor=levelOrder -q exec:exec
-Dexec.executable=echo -Dexec.args="%classpath"
Apache Maven 3.9.5-SNAPSHOT (bf3261cc66fd653ed3457153b2bfbe9bbc7d5d7b)
Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.5-SNAPSHOT
Java version: 17.0.8, vendor: Eclipse Adoptium, runtime:
/home/cstamas/.sdkman/candidates/java/17.0.8-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.4.6-200.fc38.x86_64", arch: "amd64", family:
"unix"
/home/cstamas/tmp/MNG-6357/triangle-linkage-error/main/target/classes:/home/cstamas/.m2/repository-oss/suztomo/artifact1/0.0.1-SNAPSHOT/artifact1-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact2/0.0.1-SNAPSHOT/artifact2-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact3/0.0.1-SNAPSHOT/artifact3-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact4/0.0.1-SNAPSHOT/artifact4-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact5/0.0.1-SNAPSHOT/artifact5-0.0.1-SNAPSHOT.jar
[cstamas@urnebes main (master %)]$
{noformat}
was (Author: cstamas):
The PR with [~suztomo] reproducer:
{noformat}
[cstamas@urnebes main (master %)]$ mvn -V
-Daether.system.resolveDependencies.visitor=preOrder -q exec:exec
-Dexec.executable=echo -Dexec.args="%classpath"
Apache Maven 3.9.5-SNAPSHOT (bf3261cc66fd653ed3457153b2bfbe9bbc7d5d7b)
Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.5-SNAPSHOT
Java version: 17.0.8, vendor: Eclipse Adoptium, runtime:
/home/cstamas/.sdkman/candidates/java/17.0.8-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.4.6-200.fc38.x86_64", arch: "amd64", family:
"unix"
/home/cstamas/tmp/MNG-6357/triangle-linkage-error/main/target/classes:/home/cstamas/.m2/repository-oss/suztomo/artifact1/0.0.1-SNAPSHOT/artifact1-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact4/0.0.1-SNAPSHOT/artifact4-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact2/0.0.1-SNAPSHOT/artifact2-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact5/0.0.1-SNAPSHOT/artifact5-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact3/0.0.1-SNAPSHOT/artifact3-0.0.1-SNAPSHOT.jar
[cstamas@urnebes main (master %)]$ mvn -V
-Daether.system.resolveDependencies.visitor=levelOrder -q exec:exec
-Dexec.executable=echo -Dexec.args="%classpath"
Apache Maven 3.9.5-SNAPSHOT (bf3261cc66fd653ed3457153b2bfbe9bbc7d5d7b)
Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.5-SNAPSHOT
Java version: 17.0.8, vendor: Eclipse Adoptium, runtime:
/home/cstamas/.sdkman/candidates/java/17.0.8-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.4.6-200.fc38.x86_64", arch: "amd64", family:
"unix"
/home/cstamas/tmp/MNG-6357/triangle-linkage-error/main/target/classes:/home/cstamas/.m2/repository-oss/suztomo/artifact1/0.0.1-SNAPSHOT/artifact1-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact2/0.0.1-SNAPSHOT/artifact2-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact3/0.0.1-SNAPSHOT/artifact3-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact4/0.0.1-SNAPSHOT/artifact4-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact5/0.0.1-SNAPSHOT/artifact5-0.0.1-SNAPSHOT.jar
[cstamas@urnebes main (master %)]$
{noformat}
> Dependency order should be nearest first
> -
>
> Key: MNG-6357
> URL:
[jira] [Commented] (MNG-6357) Dependency order should be nearest first
[
https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748655#comment-17748655
]
Tamas Cservenak commented on MNG-6357:
--
The PR with [~suztomo] reproducer:
{noformat}
[cstamas@urnebes main (master %)]$ mvn -V
-Daether.system.resolveDependencies.visitor=preOrder -q exec:exec
-Dexec.executable=echo -Dexec.args="%classpath"
Apache Maven 3.9.5-SNAPSHOT (bf3261cc66fd653ed3457153b2bfbe9bbc7d5d7b)
Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.5-SNAPSHOT
Java version: 17.0.8, vendor: Eclipse Adoptium, runtime:
/home/cstamas/.sdkman/candidates/java/17.0.8-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.4.6-200.fc38.x86_64", arch: "amd64", family:
"unix"
/home/cstamas/tmp/MNG-6357/triangle-linkage-error/main/target/classes:/home/cstamas/.m2/repository-oss/suztomo/artifact1/0.0.1-SNAPSHOT/artifact1-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact4/0.0.1-SNAPSHOT/artifact4-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact2/0.0.1-SNAPSHOT/artifact2-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact5/0.0.1-SNAPSHOT/artifact5-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact3/0.0.1-SNAPSHOT/artifact3-0.0.1-SNAPSHOT.jar
[cstamas@urnebes main (master %)]$ mvn -V
-Daether.system.resolveDependencies.visitor=levelOrder -q exec:exec
-Dexec.executable=echo -Dexec.args="%classpath"
Apache Maven 3.9.5-SNAPSHOT (bf3261cc66fd653ed3457153b2bfbe9bbc7d5d7b)
Maven home: /home/cstamas/.sdkman/candidates/maven/3.9.5-SNAPSHOT
Java version: 17.0.8, vendor: Eclipse Adoptium, runtime:
/home/cstamas/.sdkman/candidates/java/17.0.8-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.4.6-200.fc38.x86_64", arch: "amd64", family:
"unix"
/home/cstamas/tmp/MNG-6357/triangle-linkage-error/main/target/classes:/home/cstamas/.m2/repository-oss/suztomo/artifact1/0.0.1-SNAPSHOT/artifact1-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact2/0.0.1-SNAPSHOT/artifact2-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact3/0.0.1-SNAPSHOT/artifact3-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact4/0.0.1-SNAPSHOT/artifact4-0.0.1-SNAPSHOT.jar:/home/cstamas/.m2/repository-oss/suztomo/artifact5/0.0.1-SNAPSHOT/artifact5-0.0.1-SNAPSHOT.jar
[cstamas@urnebes main (master %)]$
{noformat}
> Dependency order should be nearest first
> -
>
> Key: MNG-6357
> URL: https://issues.apache.org/jira/browse/MNG-6357
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
> Fix For: 4.0.x-candidate
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In case of version conflicts, the nearest wins. However, the dependency order
> is simply based on tree walking. In the rare that a transitive dependency of
> the first direct dependency contains the same class as a latter direct
> dependency, the code is compiled against the first one, which is odd.
> It would make more sense if direct dependencies are the first ones on the
> classpath, followed by the first level transitive dependencies, etc. This
> will make the explanation equal to version conflict resolution: nearest wins.
> I don't expect real issues due to this change, otherwise we would have had
> this issue much earlier. This should become the new default order, however
> there should be a system property to get the original order, just in case
> somebody needs it.
>
> Current workaround: make the critical dependency the first direct dependency.
--
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=17748595#comment-17748595 ] ASF GitHub Bot commented on MNG-7848: - kun-lu20 commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1655617325 Hi @olamy , Our team (Linux on IBM Z Open Source Team) will maintain/monitor the Jenkins job. Sure, I'll update the `Notifications` stage to send emails to us. I'll get back to you once the change is done. 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)
[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-1655617325 Hi @olamy , Our team (Linux on IBM Z Open Source Team) will maintain/monitor the Jenkins job. Sure, I'll update the `Notifications` stage to send emails to us. I'll get back to you once the change is done. Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-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=17748591#comment-17748591
]
Jorge Solórzano commented on MJAR-275:
--
Please note that the fix done in [https://bugs.openjdk.org/browse/JDK-8258117]
in the JDK 18 only partially fixes the problem, from my findings, JDK 18 does
fix the {{module-info.class}} timestamp, BUT if the {{Main-Class}} attribute is
set, then the {{MANIFEST.MF}} is updated without preserving the timestamp. In
other words, this fix does not work correctly as it breaks reproducible build
anyway in that scenario, this fix is NOT used in Maven as is not reliable.
The ACTUAL fix done in Maven uses a new feature implemented in JDK 19+ and
backported to JDK 18.0.1+ and JDK 17.0.3+, the issue for that feature is this
one: [https://bugs.openjdk.org/browse/JDK-8277755] , it basically leverage a
feature to pass the --date parameter to the jar tool, plexus-archiver has
detection if this feature exists, so it works the same in JDK 17.0.2 (which
doesn't have the feature) and JDK 17.0.3+, and at the same time works with
previous versions even JDK 9.
The inclusion of JDK patch version information is another topic that should be
tackled, and yes, we should open a JDK issue for it, yet a fix for this could
take a while and there is no real hope to get a backport for it in earlier
versions of the JDK, so yes, we could provide a workaround here too, and I was
hoping to work on this, but due to lack of time I wasn't able to check this,
maybe someone could step up and work on this... my guess is that we should do
some byte-code manipulation to remove the patch version on the post-processing
phase, it might require using {*}_ASM_{*}, Byte Buddy or whatever to manipulate
the _module-info.class_ and remove that field leaving it like if the
compilation was done with a newer JDK version. Maybe someone from the ModiTect
team could help us here.
As of today, the workaround remains to use a newer JDK version to compile the
project using the --release.
Also, please note that this should be a new Jira issue, the timestamp is fixed
in Maven, but the JDK patch version is not, both affect reproducible builds,
but at the same time are not related to each other, so I propose to track the
Patch version in another ticket and create a link that is related to this one.
> 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] [Created] (MPMD-383) PMD should fail when there is a processing error
Thomas Nikolay created MPMD-383:
---
Summary: PMD should fail when there is a processing error
Key: MPMD-383
URL: https://issues.apache.org/jira/browse/MPMD-383
Project: Maven PMD Plugin
Issue Type: Improvement
Components: PMD
Affects Versions: 3.21.0
Reporter: Thomas Nikolay
Attachments: image-2023-07-28-13-34-28-717.png
We had the case that PMD can't process some processing error but the build does
not fail.
{noformat}
[2023-07-28T10:59:44.102Z] [INFO] --- maven-pmd-plugin:3.20.0:pmd (pmd) @
mod-config-client-cst ---
[2023-07-28T10:59:44.692Z] [INFO] PMD version: 6.53.0
[2023-07-28T10:59:45.672Z] [WARNING] Removed misconfigured rule:
GK-SAP-ApacheLoggerDeniedRule cause: missing value
[2023-07-28T10:59:45.672Z] [WARNING] There are 3 PMD processing errors:
[2023-07-28T10:59:45.672Z] [WARNING]
/var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java:
PMDException: Error while processing
/var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java
[2023-07-28T10:59:45.948Z]
/var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java:
PMDException: Error while processing
/var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java
[2023-07-28T10:59:45.948Z]
/var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java:
PMDException: Error while processing
/var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java
[2023-07-28T10:59:45.948Z] [INFO] Rendering content with
org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
[2023-07-28T10:59:46.210Z] [INFO]
[2023-07-28T10:59:46.210Z] [INFO] <<< maven-pmd-plugin:3.20.0:check (pmd-check)
< :pmd @ mod-config-client-cst <<<
{noformat}
My expectation would be that the build failed when there a processing errors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7855) Dependencies wrongly put on class-path rather than module-path
[
https://issues.apache.org/jira/browse/MNG-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748556#comment-17748556
]
Martin Desruisseaux edited comment on MNG-7855 at 7/28/23 11:30 AM:
Java code for generating workarounds has been added in the [test case GitHub
repository|https://github.com/Geomatys/MavenModulepathBug], in the
{{workaround}} sub-directory. That code parses de {{module-info.class}} entries
of all specified JAR files and generates a {{META-INF/services/}} directory
with all service providers found. If a service provider declares a public
static {{provider()}} method, then the program also generates a {{java}}
sub-directory with Java code for wrappers. Those wrappers redirect all methods
of the service interface to the same methods of the provider obtained by a call
to the {{provider()}} static method.
Note that this workaround does not fix the real issue, which is that
dependencies are loaded as unnamed modules when they should not. The workaround
allows libraries and application to find some service providers despite this
problem, sometime not in the way that the providers should be (because of
wrappers). But any other features that depend on named modules are still broken.
was (Author: desruisseaux):
Java code for generating workarounds has been added in the [test case GitHub
repository|https://github.com/Geomatys/MavenModulepathBug], in the
{{workaround}} sub-directory. That code parses de {{module-info.class}} entries
of all specified JAR files and generates a {{META-INF/services/}} directory
with all service providers found. If a service provider declares a public
static {{provider()}} method, then the program also generates a {{java}}
sub-directory with Java code for wrappers. Those wrappers redirect all methods
of the service interface to the same methods of the provider obtained by a call
to the {{provider()}} static method.
This workaround is of course unsatisfying, especially the wrappers which will
not work in all cases.
> Dependencies wrongly put on class-path rather than module-path
> --
>
> Key: MNG-7855
> URL: https://issues.apache.org/jira/browse/MNG-7855
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.6, 4.0.0-alpha-7
>Reporter: Martin Desruisseaux
>Priority: Blocker
> Attachments: MavenModulepathBug.zip
>
>
> When invoking Java tools such as {{java}} or {{javac}}, the project
> dependencies can be declared either in a {{\--class-path}} or
> {{\--module-path}} option. Maven choose automatically the module-path if all
> the following conditions are true:
> # the dependency is modularized (i.e. contains a {{module-info.class}} file
> or an {{Automatic-Module-Name}} attribute in {{MANIFEST.MF}}), and
> # the project using the dependency is itself modularized.
> Condition #1 is fine, but #2 is problematic. The fact that a dependency is
> declared on the class-path rather than the module-path changes the way that
> {{java.util.ServiceLoader}} discovers the provided services.
> * If the dependency is on the class-path, {{ServiceLoader}} scans the content
> of {{META-INF/services}} directory.
> * If the dependency is on the module-path, {{ServiceLoader}} uses the
> declarations in {{module-info.class}}.
> Even if condition #2 is false (i.e. a project is not modularized),
> modularized dependencies still need to be declared on the module-path _for
> allowing the dependency to discover its own services, or the services of a
> transitive modularized dependency_. If a modularized dependency is put on the
> class-path instead, it has consequence not only for the project using that
> dependency, *but also for the dependency itself, which become unable to use
> its own {{module-info.class}}*.
> h1. Demonstration
> The attached test case contains two Maven modules, named {{service}} and
> {{client}}. The first Maven module declares a dummy services with 4
> providers, named A, B, C and D. Providers A and D are declared in
> {{module-info}}. Providers B and C are declared in {{META-INF/services}}. A
> {{ShowMyServices}} class lists the services discovered by
> {{java.util.ServiceLoader}}.
> The second Maven module has only a main method invoking {{ShowMyServices}}.
> This second module intentionally has no {{module-info.java}} file. The use
> case is a big module that we cannot modularize immediately (because
> modularization brings stronger encapsulation, which requires significant
> changes in the project to modularize), but still want to use modularized
> dependencies. The test case can be run with {{mvn install}}. During test
> execution, the following is printed:
> {noformat}
> Running test.client.MainTest
> Start searching for
[jira] [Commented] (MSKINS-229) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/MSKINS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748562#comment-17748562
]
Konrad Windszus commented on MSKINS-229:
[~michael-o] Can you take over here? I don't know which approach you actually
prefer to restore working TOC anchor links.
> Inconsistent anchors between toc macro and headers
> --
>
> Key: MSKINS-229
> URL: https://issues.apache.org/jira/browse/MSKINS-229
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNGSITE-502) Document activation based on packaging
[ https://issues.apache.org/jira/browse/MNGSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748558#comment-17748558 ] ASF GitHub Bot commented on MNGSITE-502: kwin commented on PR #379: URL: https://github.com/apache/maven-site/pull/379#issuecomment-1655498367 The issue with the broken TOC links needs to be fixed in fluido most probably: https://issues.apache.org/jira/browse/MSKINS-229 > Document activation based on packaging > -- > > Key: MNGSITE-502 > URL: https://issues.apache.org/jira/browse/MNGSITE-502 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > https://issues.apache.org/jira/browse/MNG-6609 introduced profile activation > based on packaging. This requires updates of both > * [https://maven.apache.org/pom.html#Activation] and > * > [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#details-on-profile-activation] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNGSITE-502) Document activation based on packaging
[ https://issues.apache.org/jira/browse/MNGSITE-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed MNGSITE-502. --- Resolution: Fixed > Document activation based on packaging > -- > > Key: MNGSITE-502 > URL: https://issues.apache.org/jira/browse/MNGSITE-502 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > https://issues.apache.org/jira/browse/MNG-6609 introduced profile activation > based on packaging. This requires updates of both > * [https://maven.apache.org/pom.html#Activation] and > * > [https://maven.apache.org/guides/introduction/introduction-to-profiles.html#details-on-profile-activation] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSKINS-229) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/MSKINS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned MSKINS-229:
--
Assignee: (was: Konrad Windszus)
> Inconsistent anchors between toc macro and headers
> --
>
> Key: MSKINS-229
> URL: https://issues.apache.org/jira/browse/MSKINS-229
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] kwin commented on pull request #379: [MNGSITE-502] Document profile activation based on packaging
kwin commented on PR #379: URL: https://github.com/apache/maven-site/pull/379#issuecomment-1655498367 The issue with the broken TOC links needs to be fixed in fluido most probably: https://issues.apache.org/jira/browse/MSKINS-229 -- 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-7855) Dependencies wrongly put on class-path rather than module-path
[
https://issues.apache.org/jira/browse/MNG-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748556#comment-17748556
]
Martin Desruisseaux commented on MNG-7855:
--
Java code for generating workarounds has been added in the [test case GitHub
repository|https://github.com/Geomatys/MavenModulepathBug], in the
{{workaround}} sub-directory. That code parses de {{module-info.class}} entries
of all specified JAR files and generates a {{META-INF/services/}} directory
with all service providers found. If a service provider declares a public
static {{provider()}} method, then the program also generates a {{java}}
sub-directory with Java code for wrappers. Those wrappers redirect all methods
of the service interface to the same methods of the provider obtained by a call
to the {{provider()}} static method.
This workaround is of course unsatisfying, especially the wrappers which will
not work in all cases.
> Dependencies wrongly put on class-path rather than module-path
> --
>
> Key: MNG-7855
> URL: https://issues.apache.org/jira/browse/MNG-7855
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.6, 4.0.0-alpha-7
>Reporter: Martin Desruisseaux
>Priority: Blocker
> Attachments: MavenModulepathBug.zip
>
>
> When invoking Java tools such as {{java}} or {{javac}}, the project
> dependencies can be declared either in a {{\--class-path}} or
> {{\--module-path}} option. Maven choose automatically the module-path if all
> the following conditions are true:
> # the dependency is modularized (i.e. contains a {{module-info.class}} file
> or an {{Automatic-Module-Name}} attribute in {{MANIFEST.MF}}), and
> # the project using the dependency is itself modularized.
> Condition #1 is fine, but #2 is problematic. The fact that a dependency is
> declared on the class-path rather than the module-path changes the way that
> {{java.util.ServiceLoader}} discovers the provided services.
> * If the dependency is on the class-path, {{ServiceLoader}} scans the content
> of {{META-INF/services}} directory.
> * If the dependency is on the module-path, {{ServiceLoader}} uses the
> declarations in {{module-info.class}}.
> Even if condition #2 is false (i.e. a project is not modularized),
> modularized dependencies still need to be declared on the module-path _for
> allowing the dependency to discover its own services, or the services of a
> transitive modularized dependency_. If a modularized dependency is put on the
> class-path instead, it has consequence not only for the project using that
> dependency, *but also for the dependency itself, which become unable to use
> its own {{module-info.class}}*.
> h1. Demonstration
> The attached test case contains two Maven modules, named {{service}} and
> {{client}}. The first Maven module declares a dummy services with 4
> providers, named A, B, C and D. Providers A and D are declared in
> {{module-info}}. Providers B and C are declared in {{META-INF/services}}. A
> {{ShowMyServices}} class lists the services discovered by
> {{java.util.ServiceLoader}}.
> The second Maven module has only a main method invoking {{ShowMyServices}}.
> This second module intentionally has no {{module-info.java}} file. The use
> case is a big module that we cannot modularize immediately (because
> modularization brings stronger encapsulation, which requires significant
> changes in the project to modularize), but still want to use modularized
> dependencies. The test case can be run with {{mvn install}}. During test
> execution, the following is printed:
> {noformat}
> Running test.client.MainTest
> Start searching for services...
> Provider B declared in META-INF.
> Provider C declared in META-INF.
> Done.
> The dependency has been loaded as an unnamed module.
> Consequently its `module-info` file has been ignored,
> and the `META-INF/services` directory is used instead.
> {noformat}
> The above test demonstrates that {{module-info}} has been ignored in the
> context of JUnit test execution. The same behaviour happens also with {{mvn
> exec:java}} executed in the {{client}} sub-directory.
> h2. Expected behaviour
> The Maven behaviour can be reproduced on the command-line as below (Linux
> convention). This command put everything on the class-path:
> {code:bash}
> java --class-path service/target/service-1.0.jar:client/target/client-1.0.jar
> test.client.Main
> {code}
> The expected behaviour can be reproduced with the following command-line.
> This command put the modularized dependency on the module-path while keeping
> the non-modularized client on the class-path:
> {code:bash}
> java --module-path service/target/service-1.0.jar --class-path
> client/target/client-1.0.jar --add-modules ALL-MODULE-PATH
[jira] [Commented] (MNGSITE-372) Profile activation documentation is out of date
[ https://issues.apache.org/jira/browse/MNGSITE-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748547#comment-17748547 ] ASF GitHub Bot commented on MNGSITE-372: kwin merged PR #443: URL: https://github.com/apache/maven-site/pull/443 > Profile activation documentation is out of date > --- > > Key: MNGSITE-372 > URL: https://issues.apache.org/jira/browse/MNGSITE-372 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Gili >Assignee: Herve Boutemy >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Per > https://issues.apache.org/jira/browse/MNG-4565?focusedCommentId=16844101=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16844101: > http://maven.apache.org/pom.html#Activation needs to be updated to indicate > that *all* activation conditions must be true for a profile to activate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2097) More configuration for surefire JPMS
[
https://issues.apache.org/jira/browse/SUREFIRE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748544#comment-17748544
]
Martin Desruisseaux commented on SUREFIRE-2097:
---
Thanks for the reply! Does it means that MNG-7855 issue is actually a
{{plexus-languages}} issue? In that case, do you know if there is anyway to
tell plexus to put dependencies on the module-path rather than class-path?
> More configuration for surefire JPMS
>
>
> Key: SUREFIRE-2097
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2097
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 3.0.0-M7
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
>
> Currently surefire manages the build of module path and classpath graph with
> almost not configurable option.
> Due to long time between M5 and M6 releases while in the meantime plexus-java
> has incorporated a lot changes (for compiler, javadoc), those release has
> created some backward incompatible changes which are affecting some users
> such:
> - https://issues.apache.org/jira/browse/SUREFIRE-2057
> - comments here [https://github.com/eclipse/jetty.project/pull/8129]
> So we need few more options to be able to configure some of the assumptions
> which has been made and changed in plexus-java.
> Because the current configuration is hardcoded:
> {code:java}
> ResolvePathsRequest req = ResolvePathsRequest.ofStrings(
> testClasspath.getClassPath() )
> .setIncludeAllProviders( true )
> .setJdkHome( javaHome )
> .setIncludeStatic( true )
> .setModuleDescriptor( javaModuleDescriptor );
> {code}
> We must give users some options to override the black magic made by
> plexus-java.
> Options to configure:
> - force all test/provided scope to be in classpath or not
> - do not add automatically providers to the module path
> - a possible list per groupId/artifactId to force module path or classpath
> - etc...
> The idea here is too collect what users need.
> Remember we will try to avoid too much complicated options :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNGSITE-372) Profile activation documentation is out of date
[ https://issues.apache.org/jira/browse/MNGSITE-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748535#comment-17748535 ] ASF GitHub Bot commented on MNGSITE-372: kwin opened a new pull request, #443: URL: https://github.com/apache/maven-site/pull/443 Minor fixes > Profile activation documentation is out of date > --- > > Key: MNGSITE-372 > URL: https://issues.apache.org/jira/browse/MNGSITE-372 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Gili >Assignee: Herve Boutemy >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Per > https://issues.apache.org/jira/browse/MNG-4565?focusedCommentId=16844101=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16844101: > http://maven.apache.org/pom.html#Activation needs to be updated to indicate > that *all* activation conditions must be true for a profile to activate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7854) Imported entries that are ignored should be emitted as warning
[ https://issues.apache.org/jira/browse/MNG-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748513#comment-17748513 ] Slawomir Jaranowski commented on MNG-7854: -- I would like to be careful with it. Especially with spring boot configurations and overridden some of artifacts. https://docs.spring.io/spring-boot/docs/3.1.2/maven-plugin/reference/htmlsingle/#using.import > Imported entries that are ignored should be emitted as warning > -- > > Key: MNG-7854 > URL: https://issues.apache.org/jira/browse/MNG-7854 > Project: Maven > Issue Type: Improvement > Components: POM >Reporter: Tamas Cservenak >Priority: Major > > See https://github.com/cstamas/MNG-7852 for reproducer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2097) More configuration for surefire JPMS
[
https://issues.apache.org/jira/browse/SUREFIRE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748510#comment-17748510
]
Olivier Lamy commented on SUREFIRE-2097:
Well actually it's not exactly the same issue :)
The MNG issue will have a more generic setup but currently it's done by
https://github.com/codehaus-plexus/plexus-languages.
> More configuration for surefire JPMS
>
>
> Key: SUREFIRE-2097
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2097
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 3.0.0-M7
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
>
> Currently surefire manages the build of module path and classpath graph with
> almost not configurable option.
> Due to long time between M5 and M6 releases while in the meantime plexus-java
> has incorporated a lot changes (for compiler, javadoc), those release has
> created some backward incompatible changes which are affecting some users
> such:
> - https://issues.apache.org/jira/browse/SUREFIRE-2057
> - comments here [https://github.com/eclipse/jetty.project/pull/8129]
> So we need few more options to be able to configure some of the assumptions
> which has been made and changed in plexus-java.
> Because the current configuration is hardcoded:
> {code:java}
> ResolvePathsRequest req = ResolvePathsRequest.ofStrings(
> testClasspath.getClassPath() )
> .setIncludeAllProviders( true )
> .setJdkHome( javaHome )
> .setIncludeStatic( true )
> .setModuleDescriptor( javaModuleDescriptor );
> {code}
> We must give users some options to override the black magic made by
> plexus-java.
> Options to configure:
> - force all test/provided scope to be in classpath or not
> - do not add automatically providers to the module path
> - a possible list per groupId/artifactId to force module path or classpath
> - etc...
> The idea here is too collect what users need.
> Remember we will try to avoid too much complicated options :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7854) Imported entries that are ignored should be emitted as warning
[ https://issues.apache.org/jira/browse/MNG-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748447#comment-17748447 ] ASF GitHub Bot commented on MNG-7854: - cstamas commented on PR #1211: URL: https://github.com/apache/maven/pull/1211#issuecomment-1655185283 This combined with https://issues.apache.org/jira/browse/MNG-5600 could be a solution > Imported entries that are ignored should be emitted as warning > -- > > Key: MNG-7854 > URL: https://issues.apache.org/jira/browse/MNG-7854 > Project: Maven > Issue Type: Improvement > Components: POM >Reporter: Tamas Cservenak >Priority: Major > > See https://github.com/cstamas/MNG-7852 for reproducer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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=17748433#comment-17748433
]
Herve Boutemy edited comment on MJAR-275 at 7/28/23 6:36 AM:
-
done https://bugs.openjdk.org/browse/JDK-8258117, fixed in JDK 18
IIRC, our code does workaround for older JDK releases, but uses the new feature
with JDK 18+
was (Author: hboutemy):
done https://bugs.openjdk.org/browse/JDK-8258117, fixed in JDK 18
> 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] [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=17748433#comment-17748433
]
Herve Boutemy commented on MJAR-275:
done https://bugs.openjdk.org/browse/JDK-8258117, fixed in JDK 18
> 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)
