[jira] [Updated] (MRESOLVER-27) turn artifacts into Java 9 modules
[ https://issues.apache.org/jira/browse/MRESOLVER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRESOLVER-27: Description: Java 9 with Jigsaw modules is coming Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning artifacts into real Java 9 modules would be more powerful, even if it requires more work NOTE: partly done for api, spi and utils in https://github.com/apache/maven-resolver/commit/8266e6c320a7cf4deed3deb253ff4fd506d1d8f2 was: Java 9 with Jigsaw modules is coming Maven Artifact Resolver: # has a chance to be turned into Java 9 modules # could be useful as Java 9 modules Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning artifacts into real Java 9 modules would be more powerful, even if it requires more work > turn artifacts into Java 9 modules > -- > > Key: MRESOLVER-27 > URL: https://issues.apache.org/jira/browse/MRESOLVER-27 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Affects Versions: Maven Artifact Resolver 1.1.0 >Reporter: Herve Boutemy >Priority: Minor > > Java 9 with Jigsaw modules is coming > Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning > artifacts into real Java 9 modules would be more powerful, even if it > requires more work > NOTE: partly done for api, spi and utils in > https://github.com/apache/maven-resolver/commit/8266e6c320a7cf4deed3deb253ff4fd506d1d8f2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8163) MavenSessionBuilderSupplier depends on Resolver internal code
[ https://issues.apache.org/jira/browse/MNG-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856724#comment-17856724 ] Robert Scholte commented on MNG-8163: - Tools like IDEs, CI-servers and maybe even other tools need to have a consistent way of resolving dependencies (I'd prefer to call it m2 style, to make a clear difference with the Maven buildtool) and they might be using the modulepath. One way to solve this, is to export these packages only to the maven-api-impl module. > MavenSessionBuilderSupplier depends on Resolver internal code > - > > Key: MNG-8163 > URL: https://issues.apache.org/jira/browse/MNG-8163 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Tamas Cservenak >Priority: Major > > See current most recent tag: > https://github.com/apache/maven/blob/maven-4.0.0-beta-3/maven-api-impl/src/main/java/org/apache/maven/internal/impl/resolver/MavenSessionBuilderSupplier.java#L37-L42 > Once MRESOLVER-27 is in place I expect that these internal packages are not > accessible anymore (for those using the modulepath). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8163) MavenSessionBuilderSupplier depends on Resolver internal code
Robert Scholte created MNG-8163: --- Summary: MavenSessionBuilderSupplier depends on Resolver internal code Key: MNG-8163 URL: https://issues.apache.org/jira/browse/MNG-8163 Project: Maven Issue Type: Improvement Reporter: Robert Scholte Assignee: Tamas Cservenak See current most recent tag: https://github.com/apache/maven/blob/maven-4.0.0-beta-3/maven-api-impl/src/main/java/org/apache/maven/internal/impl/resolver/MavenSessionBuilderSupplier.java#L37-L42 Once MRESOLVER-27 is in place I expect that these internal packages are not accessible anymore (for those using the modulepath). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-573) CollectionConfiguration should ignore module-info.java
[ https://issues.apache.org/jira/browse/MRESOLVER-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRESOLVER-573. Resolution: Fixed > CollectionConfiguration should ignore module-info.java > -- > > Key: MRESOLVER-573 > URL: https://issues.apache.org/jira/browse/MRESOLVER-573 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > This is in preparation of MRESOLVER-27 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-573) CollectionConfiguration should ignore module-info.java
Robert Scholte created MRESOLVER-573: Summary: CollectionConfiguration should ignore module-info.java Key: MRESOLVER-573 URL: https://issues.apache.org/jira/browse/MRESOLVER-573 Project: Maven Resolver Issue Type: Improvement Reporter: Robert Scholte This is in preparation of MRESOLVER-27 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-27) turn artifacts into Java 9 modules
[ https://issues.apache.org/jira/browse/MRESOLVER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856440#comment-17856440 ] Robert Scholte commented on MRESOLVER-27: - Let's start by providing module descriptors for the modules that don't have dependecies or don't rely on third party dependencies. So that's maven-resolver-api, maven-resolver-spi and maven-resolver-util. I'll prepare a MR. > turn artifacts into Java 9 modules > -- > > Key: MRESOLVER-27 > URL: https://issues.apache.org/jira/browse/MRESOLVER-27 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Affects Versions: Maven Artifact Resolver 1.1.0 >Reporter: Herve Boutemy >Priority: Minor > > Java 9 with Jigsaw modules is coming > Maven Artifact Resolver: > # has a chance to be turned into Java 9 modules > # could be useful as Java 9 modules > Automatic Modules Names in MRESOLVER-26 is a quickstart, but turning > artifacts into real Java 9 modules would be more powerful, even if it > requires more work -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-137) Can't match distributionUrl when using MINGW64
Robert Scholte created MWRAPPER-137:
---
Summary: Can't match distributionUrl when using MINGW64
Key: MWRAPPER-137
URL: https://issues.apache.org/jira/browse/MWRAPPER-137
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Scripts
Affects Versions: 3.3.1
Reporter: Robert Scholte
Any mvnw command fails with the following message:
{noformat}
$ ./mvnw verify
'istributionUrl is not valid, must match *-bin.zip or maven-mvnd-*.zip, but
found
'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/4.0.0-alpha-13/apache-maven-4.0.0-alpha-13-bin.zip
{noformat}
Also notice that the {{d}} from distributionUrl has been replaced with a single
quote.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJLINK-80) Support additional resources
[ https://issues.apache.org/jira/browse/MJLINK-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJLINK-80. Fix Version/s: 3.3.0 Assignee: Robert Scholte Resolution: Fixed Fixed with https://github.com/apache/maven-jlink-plugin/commit/a6e3a10dcfbf7b936748fd3e21e3dc54972f2a15 > Support additional resources > > > Key: MJLINK-80 > URL: https://issues.apache.org/jira/browse/MJLINK-80 > Project: Maven JLink Plugin > Issue Type: New Feature >Affects Versions: 3.2.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.3.0 > > > This plugin does 2 steps into 1: > # run the jlink-command to create the image files into an empty directory > # bundle the content into a jar. > You cannot prepare resources into the jlink output directory, because jlink > will fail. > So this plugin must be extended to support additional resoures. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJLINK-80) Support additional resources
Robert Scholte created MJLINK-80: Summary: Support additional resources Key: MJLINK-80 URL: https://issues.apache.org/jira/browse/MJLINK-80 Project: Maven JLink Plugin Issue Type: New Feature Affects Versions: 3.2.0 Reporter: Robert Scholte This plugin does 2 steps into 1: # run the jlink-command to create the image files into an empty directory # bundle the content into a jar. You cannot prepare resources into the jlink output directory, because jlink will fail. So this plugin must be extended to support additional resoures. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSCRIPTING-11. Assignee: Robert Scholte Resolution: Won't Fix The original question to expose the lifecycle or phase will not be supported. By using execution-blocks you already control the phase in which is it executed. > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Assignee: Robert Scholte >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSCRIPTING-10) Page Not Found on majority of Maven Scripting Plugin pages
[ https://issues.apache.org/jira/browse/MSCRIPTING-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MSCRIPTING-10: - Description: On page https://maven.apache.org/plugins/maven-scripting-plugin/index.html there is "Page Not Found" response for following links: [https://maven.apache.org/plugins/maven-scripting-plugin/usage.html] [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] [https://maven.apache.org/plugins/maven-scripting-plugin/source-repository.html] was: On page https://maven.apache.org/plugins/maven-scripting-plugin/index.html there is "Page Not Found" response for following links: [https://maven.apache.org/plugins/maven-scripting-plugin/usage.html] [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] > Page Not Found on majority of Maven Scripting Plugin pages > -- > > Key: MSCRIPTING-10 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-10 > Project: Maven Scripting > Issue Type: Bug > Environment: Web >Reporter: Milan Kubec >Priority: Major > > On page https://maven.apache.org/plugins/maven-scripting-plugin/index.html > there is "Page Not Found" response for following links: > [https://maven.apache.org/plugins/maven-scripting-plugin/usage.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/source-repository.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1563) NoClassDefFoundError for JPMS modules with "require static"
[
https://issues.apache.org/jira/browse/SUREFIRE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772809#comment-17772809
]
Robert Scholte commented on SUREFIRE-1563:
--
Not sure what the status is, and what you expect here:
{{}}
{{ --add-modules=org.slf4j}}
{{}}
This works, not sure if it is enough
The rational: By default all static required modules are not added to the
runtime, as they are optional. The developer needs to decide how to execute
these tests: without these or with one or more optional(static) modules.
> NoClassDefFoundError for JPMS modules with "require static"
> ---
>
> Key: SUREFIRE-1563
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1563
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Attachments: maven-jpms.tgz
>
>
> When a Maven module has a {{module-info.java}} that contains a {{requires
> static}}, Surefire throws {{NoClassDefFoundError}} when running the tests for
> that Maven module.
> If the dependency is declared only as {{required}} (no {{static}}), then the
> tests run fine.
> Attached a reproducible project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766074#comment-17766074
]
Robert Scholte commented on MJAVADOC-682:
-
The JavadocModule uses GA as key, seems like you want GAV here:
https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/JavadocModule.java#L34
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0
> Environment: Debian Linux versions 10.10 through 12.1
> OpenJDK 64-bit versions 11.0.11 through 17.0.8
> Maven versions 3.8.1 through 3.9.4
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.6.0, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755195#comment-17755195
]
Robert Scholte commented on MCOMPILER-446:
--
Right, unless somebody creates a backport patch for Java 17. See for example
https://bugs.openjdk.org/browse/JDK-8240169 that backports can be done.
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Assignee: Robert Scholte
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7844) Support for DTD entities and XInclude in the code at build time
[ https://issues.apache.org/jira/browse/MNG-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744319#comment-17744319 ] Robert Scholte commented on MNG-7844: - Just a couple of my personnal opinions: the fact that XML can have an include mechanism doesn't mean Maven should support it. It will be a target for vulnerability injection. What's the _important_ usecase that requires this? I assume it is more about mixins, which I believe should be done based on GAV: it is just another way of handling a parent pom. > Support for DTD entities and XInclude in the code at build time > --- > > Key: MNG-7844 > URL: https://issues.apache.org/jira/browse/MNG-7844 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > The idea is to open a bit more the POM XML to composition. > The prerequisite is that the _original_ pom is not installed / uploaded > anymore and needs to be processed and trimmed, so that the consumer pom is > installed/uploaded. The consumer pom mechanism would have to be slightly > changed to make sure DTD entities and xinclude are fully processed and merged > in. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7832) revert artifact handlers move to plugins
[ https://issues.apache.org/jira/browse/MNG-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739656#comment-17739656 ] Robert Scholte commented on MNG-7832: - IIRC the reason behind the moving the artifact handler as well are custom artifacts. A small anecdote regarding custom artifact handlers: TIBCO also has the concept of applications and libraries, but they call it differently and it is XML. One of the standard Maven plugins goals (something like dependency:tree or dependency:unpack) didn't work, because Maven couldn't find the right artifact handler, because Maven was treating embedded handlers different from custom handlers. In my opinion there should be no difference between embedded and custom artifact handlers. To enforce that, I prefer to have this kind of logic in the packaging-plugin OR a better mechanism that custom artifact handlers are treated the same. > revert artifact handlers move to plugins > > > Key: MNG-7832 > URL: https://issues.apache.org/jira/browse/MNG-7832 > Project: Maven > Issue Type: Sub-task > Components: Dependencies, Plugins and Lifecycle >Reporter: Herve Boutemy >Priority: Major > > MNG-5697 proposed to move at the same time packaging mapping AND artifact > handlers to packaging-oriented plugins > packaging mapping is feasible, and can make sense: user configures a > packaging plugin in his pom.xml to benefit from the full associated build > lifecycle, why not > but attifact handler is completely another beast: it's about consuming an > artifact as a dependency, then not lead at all by the packaging of the > project consuming the artifact > we need to split the 2 aspects: > 1. finish lifecycle mapping definition to plugins, and remove at the end the > definition from core, while learning users how to not any more benefit from > implicit core definition > 2. revert artifact handlers copy to packaging plugins, because they create > confusion: artifacts will never be consumed with an artifact handler defined > by an associated packaging plugin > once someone finds something reasonable about artifact handlers, we can > implement it later -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-446.
Assignee: Robert Scholte
Resolution: Resolved
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Assignee: Robert Scholte
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737288#comment-17737288
]
Robert Scholte commented on MCOMPILER-446:
--
I think this issue should have been closed. There's already a mechanism that
automatically sets the module-version based on the project version. IMO this
should always be in sync to prevent any confusion.
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-764) Introduce 'update' goal
[ https://issues.apache.org/jira/browse/MSITE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683833#comment-17683833 ] Robert Scholte commented on MSITE-764: -- Right > Introduce 'update' goal > --- > > Key: MSITE-764 > URL: https://issues.apache.org/jira/browse/MSITE-764 > Project: Maven Site Plugin > Issue Type: New Feature >Reporter: Robert Scholte >Priority: Minor > Fix For: backlog, wontfix-candidate > > > Quite often site documentation is published as part of the release. This > means that changes to the documentation depend on a new release before being > visible OR you must accept that the documentation refers to a snapshot > version instead of the latest release version. > With the update-goal it will be possible to immediately publish > documentation changes without changes references to released project. > The siteskinner-maven-plugin > [http://www.mojohaus.org/siteskinner-maven-plugin/] (originally written by > me) at MojoHaus contains a lot of code which can form the base for this goal. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-764) Introduce 'update' goal
[ https://issues.apache.org/jira/browse/MSITE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683139#comment-17683139 ] Robert Scholte commented on MSITE-764: -- Could be, but let's document it as it is not that straightforward. And you should probably need to verify it as well. > Introduce 'update' goal > --- > > Key: MSITE-764 > URL: https://issues.apache.org/jira/browse/MSITE-764 > Project: Maven Site Plugin > Issue Type: New Feature >Reporter: Robert Scholte >Priority: Minor > Fix For: backlog, wontfix-candidate > > > Quite often site documentation is published as part of the release. This > means that changes to the documentation depend on a new release before being > visible OR you must accept that the documentation refers to a snapshot > version instead of the latest release version. > With the update-goal it will be possible to immediately publish > documentation changes without changes references to released project. > The siteskinner-maven-plugin > [http://www.mojohaus.org/siteskinner-maven-plugin/] (originally written by > me) at MojoHaus contains a lot of code which can form the base for this goal. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-489) User property for multiReleaseOutput
[ https://issues.apache.org/jira/browse/MCOMPILER-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MCOMPILER-489. Assignee: Robert Scholte Resolution: Won't Fix > User property for multiReleaseOutput > > > Key: MCOMPILER-489 > URL: https://issues.apache.org/jira/browse/MCOMPILER-489 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: John Patrick >Assignee: Robert Scholte >Priority: Minor > Labels: CompilerOptions > > Add support so multiReleaseOutput can be provided as a user property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681770#comment-17681770 ] Robert Scholte commented on MSCRIPTING-11: -- Based on those extra requirements it makes more sense to me to write your own plugin or extension. I prefer not to turn the scripting-plugin into a swiss army knife. > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[
https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681311#comment-17681311
]
Robert Scholte commented on MSCRIPTING-11:
--
I think in both cases the answer is execution-blocks
For 1: you want a script that looks like:
{code:java}
if ("compile".equals(phase)) { /* do this*/ } else if
("test-compile".equals(phase)) { /* do that*/ }
{code}
If that is the case, you'd better do this:
{code:xml}
org.apache.maven.plugins
maven-scripting-plugin
3.0.0
compile-script
compile
test-compile-script
test-compile
{code}
for 2: I would make a profile called "setup", and have a couple of execution
blocks using install:install-file
> Lifecycle
> -
>
> Key: MSCRIPTING-11
> URL: https://issues.apache.org/jira/browse/MSCRIPTING-11
> Project: Maven Scripting
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Hüseyin Kartal
>Priority: Major
> Labels: features, pull-request-available
>
> Make the current maven lifecycle phase available in the groovy script.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681236#comment-17681236 ] Robert Scholte commented on MSCRIPTING-11: -- I don't understand this request? Of course the context can be filled with these things, but every new entity might come with possible security related issues (hence I blocked adding settings, because it gives easy access to credentials). What is the usecase? > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679435#comment-17679435
]
Robert Scholte commented on MCOMPILER-481:
--
[~cstamas] what makes you think it is a plugin bug?
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-compiler-plugin/job/master/
is green. Tested succesfully locally with 3.8.7, but failed with
3.9.0-SNAPSHOT. Looks more like a Maven bug.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 3.10.0
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in
[jira] [Commented] (MNG-7595) [REGRESSION] $pom.-expressions in remote pom cause warnings
[
https://issues.apache.org/jira/browse/MNG-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631284#comment-17631284
]
Robert Scholte commented on MNG-7595:
-
The issue here is that it exists in Central, which is immutable. Fixing it
there would require resigning it. The pom reader should only be strict for
local poms, not for remote poms.
Now that we've identified this issue, I see more things that should be done:
- have a filter that resolves properties in dependencies (maybe even more) for
non pom-packaging pomfiles (I see a pattern where properties are used to
overwrite values in a parent, such as the dependency version)
- same needs to be done when there will be a pdt-file.
> [REGRESSION] $pom.-expressions in remote pom cause warnings
> ---
>
> Key: MNG-7595
> URL: https://issues.apache.org/jira/browse/MNG-7595
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-2
>Reporter: Robert Scholte
>Priority: Major
>
> When depending on
> [wagon-http-1.0-beta-6|https://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-http/1.0-beta-6/wagon-http-1.0-beta-6.pom]
> you'll get a warning like:
> {noformat}
> [WARNING] The POM for org.apache.maven.wagon:wagon-http:jar:1.0-beta-6 is
> invalid, transitive dependencies (if any) will not be available: 1 problem
> was encountered while building the effective model for
> C:\Users\rober\.m2\repository\org\apache\maven\wagon\wagon-http\1.0-beta-6\wagon-http-1.0-beta-6.pom
> [ERROR] 'dependencies.dependency.groupId' for
> ${pom.groupId}:wagon-http-shared:jar with value '${pom.groupId}' does not
> match a valid coordinate id pattern. @
> org.apache.maven.wagon:wagon-http:1.0-beta-6
> {noformat}
> Even though this is an old artifact, IMO we should not have such a warning
> for remote poms, as they cannot be changed. So the question is: do we need to
> reconsider the decision to only allow $project.-expressions for the build-pom?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7595) [REGRESSION] $pom.-expressions in remote pom cause warnings
Robert Scholte created MNG-7595:
---
Summary: [REGRESSION] $pom.-expressions in remote pom cause
warnings
Key: MNG-7595
URL: https://issues.apache.org/jira/browse/MNG-7595
Project: Maven
Issue Type: Bug
Affects Versions: 4.0.0-alpha-2
Reporter: Robert Scholte
When depending on
[wagon-http-1.0-beta-6|https://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-http/1.0-beta-6/wagon-http-1.0-beta-6.pom]
you'll get a warning like:
{noformat}
[WARNING] The POM for org.apache.maven.wagon:wagon-http:jar:1.0-beta-6 is
invalid, transitive dependencies (if any) will not be available: 1 problem was
encountered while building the effective model for
C:\Users\rober\.m2\repository\org\apache\maven\wagon\wagon-http\1.0-beta-6\wagon-http-1.0-beta-6.pom
[ERROR] 'dependencies.dependency.groupId' for
${pom.groupId}:wagon-http-shared:jar with value '${pom.groupId}' does not match
a valid coordinate id pattern. @ org.apache.maven.wagon:wagon-http:1.0-beta-6
{noformat}
Even though this is an old artifact, IMO we should not have such a warning for
remote poms, as they cannot be changed. So the question is: do we need to
reconsider the decision to only allow $project.-expressions for the build-pom?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MEAR-322) Module repackaged as invalid archive
[
https://issues.apache.org/jira/browse/MEAR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622799#comment-17622799
]
Robert Scholte commented on MEAR-322:
-
Everybody can report a bug, but due to a huge amount of spam, they are first
validated before being moved to a JDK- issue. People that have proven their
value sometimes get direct access, I'm one of the few.
The easiest way is to say what you want to be added, I'll copy/paste when I
agree.
I'm not going to ask for backports if it is already fixed in a newer version.
So if this is a JDK11 issue, better to provide a backport patch on that branch.
> Module repackaged as invalid archive
>
>
> Key: MEAR-322
> URL: https://issues.apache.org/jira/browse/MEAR-322
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Piotr Zygielo
>Priority: Major
> Fix For: more-investigation
>
>
> After m-ear-p upgrade from 3.2.0 to 3.3.0, ear produced by plugin contains
> invalid entry. That causes jar tool to error with
> {quote}java.util.zip.ZipException: only DEFLATED entries can have EXT
> descriptor
> at java.base/java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:313)
> at
> java.base/java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:125)
> at jdk.jartool/sun.tools.jar.Main.extract(Main.java:1360)
> at jdk.jartool/sun.tools.jar.Main.run(Main.java:409)
> at jdk.jartool/sun.tools.jar.Main.main(Main.java:1680)
> {quote}
> Seems to be connected to setting {{archive/compress=false}} in the original
> jar project (original project - valid at its origin, becomes invalid part of
> ear).
> This happens for original project with {{packaging=clojure}} in my case.
> 07a84983809b4ec416b1330412bbd83844a88a44 is the first bad commit
>
>
> Reproducer: [https://github.com/pzrep/MEAR-322]
> and its failure: [https://github.com/pzrep/MEAR-322/actions/runs/3306348660]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6268 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6268/2/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-5728 #9 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5728/9/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build failed in Jenkins: Maven » Maven TLP » maven » MNG-6829 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6829/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: michael-o): Fixed with [95ee8908370744153531aa2e80a9bce93dc5d9bc|https://gitbox.apache.org/repos/asf?p=maven.git=commit=95ee8908370744153531aa2e80a9bce93dc5d9bc] and ITs with [10fd1f967dd95bf7b8451cec0a20fd88f55582c8|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git=commit=10fd1f967dd95bf7b8451cec0a20fd88f55582c8]. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6555 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6113 #3 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6113/3/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » master #65 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/65/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6888 #16 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6888/16/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6957 #12 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6957/12/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6552 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » master #64 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/64/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » master #66 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/66/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6054 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6054/2/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6114 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6114/2/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MODELTESTS_IMPROVEMENT #16 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/16/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6909 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6909/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6550 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6553 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6554 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » Bananeweizen-MNG-6907 #16 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/Bananeweizen-MNG-6907/16/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven-studies » maven-metrics #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-studies/job/maven-metrics/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6889 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6889/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-94 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-94/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-5091) Add option to fail build if WARNING's appear in POM
[
https://issues.apache.org/jira/browse/MNG-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564551#comment-17564551
]
Robert Scholte commented on MNG-5091:
-
[~astubbs] that means you either need to update those groovy dependencies or
switch to
[maven-scripting-plugin|https://maven.apache.org/plugins/maven-scripting-plugin/].
Check
https://maven.apache.org/plugins/maven-scripting-plugin/configure-the-script-engine.html
how to configure it for groovy.
> Add option to fail build if WARNING's appear in POM
> ---
>
> Key: MNG-5091
> URL: https://issues.apache.org/jira/browse/MNG-5091
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, POM
>Affects Versions: 3.0.3
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Attachments: MNG-5091-maven-embedder.patch
>
>
> It would be nice to have the option to let a build fail if something like
> this will appear:
> {code}
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.soebes.training.module:050-project-without-warnings:jar:0.1.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version 1.6.1
> @ line 28, column 14
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {code}
> This shoud be done for WARNING's in case of missing versions for plugins etc.
> Currently it is possible to set the Validation leven in Jenkins/Hudson
> already but it is not possible on command line. So an option on command line
> like:
> {code}
> mvn --fail-warning ...
> {code}
> would be great. Or may be a good supplemental option to set the validation
> level like:
> {code}
> mvn --validation-level MINIMAL
> mvn --validation-level MAVEN20
> mvn --validation-level MAVEN30
> mvn --validation-level MAVEN31
> mvn --validation-level DEFAULT
> {code}
> or may be both. May this might be an enhancement for Maven 3.0.4 ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-652) Dependencies on the patch-module path
[
https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539602#comment-17539602
]
Robert Scholte commented on MJAVADOC-652:
-
Do the following steps:
- unpack your zip and run {{mvn verify -Ddebug}}
- go to target/apidocs and adjust the {{options}} file (e.g removing
servlet-api from the --patch-module argument)
- run from the target/apidocs directory {{javadoc}} and you'll see the errors.
And by the way adjusting the options is the perfect way to test your changes
before diving into the code.
The patch is required for sure. Again, try to make a reproducible project,
otherwise it is way to hard to figure out your specific problem.
> Dependencies on the patch-module path
> -
>
> Key: MJAVADOC-652
> URL: https://issues.apache.org/jira/browse/MJAVADOC-652
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0
>Reporter: Phil
>Assignee: Robert Scholte
>Priority: Major
> Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip
>
>
> When building with Java 11 (so >9) the Javadoc options argument is built
> using the module-path and patch-module. Some of the dependencies I work with
> are ending up in patch-module which generates an error on Javadoc creation -
> class not found.
> From what I can see from the code (3.2.0), the decision of which argument to
> use is based on:
> # If the dependency jar has a module-info.class, add to module-path
> # If the dependency jar has a MANIFEST file with Automatic-Module-Name
> defined, add to module-path.
> # If neither of the above, add to patch-module.
> The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets
> amended to the patch-module. This then prevents Javadoc generation because
> Java is unable to link classes from the servlet API. If I put the servlet API
> into the module-path manually it works fine.
> From my understanding, patch-module is used to either override classes in a
> module or augment contents of a module. In this case, it is its own 'module'
> (I think) and should not be patched into my module. I do not see a reason to
> put any of my dependencies into patch-module.
> Is this a bug, or just an unfortunate consequence of having to deal with
> non-modular dependencies when building under a Java version that supports
> modules. For what it is worth, the project I work on does not use modules,
> everything on -classpath works just fine.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539538#comment-17539538 ] Robert Scholte commented on MJAVADOC-652: - The plugin tries to build up the most clean possible set of arguments. Adding jars to the patch module was never done just for fun or for the easy solution, but always because there was a case that shows that it is required. > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537004#comment-17537004 ] Robert Scholte commented on MJAVADOC-652: - There should be no need for this extra parameter, I'm sure the plugin is able to predict very well how jars should be handled. As you descibed it, it does work for a single module as expected, but not in a specific multimodule setup. So please improve the IT first matching your usecase. After that we can analyse the issue and decide what to do. > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7360) Can't parse project that has tag in plugin configuration
[
https://issues.apache.org/jira/browse/MNG-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537002#comment-17537002
]
Robert Scholte commented on MNG-7360:
-
I'm almost certain there used to be a unittest for this, but I guess it has
been removed after the refactoring. Key are the any-elements in the pom. The
[FastForwardFilter|https://github.com/apache/maven/blob/master/maven-model-transform/src/main/java/org/apache/maven/model/transform/FastForwardFilter.java]
sums up all those known elements in the pom. In the original implementation I
was able to write directly to the outputstream instead of the filter, so these
elements were ignored.
I'm missing tests (both unit and it) to confirm it now works for all 6
element-blocks.
> Can't parse project that has tag in plugin configuration
> -
>
> Key: MNG-7360
> URL: https://issues.apache.org/jira/browse/MNG-7360
> Project: Maven
> Issue Type: Bug
> Components: build/consumer
>Affects Versions: 4.0.x-candidate
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (3a06530dbce82e2054afa3cc4c81631910474bd0)
> Maven home:
> /usr/local/Cellar/maven-snapshot/4.0.0-alpha-1-SNAPSHOT_290/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Maarten Mulders
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: Screenshot 2021-12-13 at 13.45.01.png
>
>
> The Apache Camel project has the following snippet in their root POM:
> {code:xml}
>
> org.codehaus.mojo
> flatten-maven-plugin
> 1.2.5
>
>
> default-cli
> process-resources
>
> flatten
>
>
>
>
>
> expand
>
>
>
>
>
>
> {code}
> With Maven 4's "Build Consumer" feature enabled, parsing this plugin
> definition breaks with
> {code:none}
> [INFO] BuildTimeEventSpy is registered.
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Unable to transform pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project (/Users/maarten/Code/open-source/camel/pom.xml) has 1
> error
> [ERROR] Unable to transform pom: Not a regular file:
> /Users/maarten/Code/open-source/pom.xml
> [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 verbose output
> [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/ProjectBuildingException
> {code}
> I suspect that the {{}} tag is the culprit. It seems to me that it
> causes the {{ParentXMLFilter}} to think it needs to do its work. The attached
> screenshot shows the stacktrace that brought me to this idea. As the
> {{BufferingParser}} class processes its buffer of events, it encounters a
> situation of an "end {{parent}} tag". But that {{parent}} tag did not have
> child elements {{version}} and {{relativePath}} and so, it decides it needs
> to resolve the parent as {{../pom.xml}} against the project path
> ({{/Users/maarten/Code/open-source/camel/}} in my case), leading to the
> non-existing path of {{/Users/maarten/Code/open-source/pom.xml}}.
> I think the bug here is not that it resolves to a non-existing path (it's
> good to check that before actually reading the file). I think the bug is that
> the {{ParentXMLFilter}} is acting on the {{parent}} tag inside the plugin
> configuration.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MJAVADOC-700) Plugin duplicates classes in Java 8 all-classes lists
[
https://issues.apache.org/jira/browse/MJAVADOC-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533224#comment-17533224
]
Robert Scholte commented on MJAVADOC-700:
-
Well, it is clearly a bug. Might be that this one was missed when moving from
String to Path where possible. It is simply about reproducing it, fixing it and
make sure no other IT fails.
> Plugin duplicates classes in Java 8 all-classes lists
> --
>
> Key: MJAVADOC-700
> URL: https://issues.apache.org/jira/browse/MJAVADOC-700
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0, 3.3.1
>Reporter: Rob Spoor
>Priority: Major
>
> Versions 3.3.0 and 3.3.1 of the Javadoc Plugin create allclasses-frame.html
> and allclasses-noframe.html files that duplicate all classes, interfaces, etc.
> To reproduce:
> * Clone https://github.com/robtimus/data-url (a simple and small project that
> can be used to showcase the issue)
> * Run {{mvn javadoc:javadoc}}, which uses version 3.2.0
> * Check target/site/apidocs/allclasses-frame.html - no duplicates
> * Run {{mvn javadoc:javadoc -Dversion.plugin.javadoc=3.3.0}} to build the
> same with version 3.3.0
> * Check target/site/apidocs/allclasses-frame.html - all classes are duplicated
> The same issue occurs with {{javadoc:aggregate}}, possibly others as well.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-6806) Provide Maven BOM
[
https://issues.apache.org/jira/browse/MNG-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532968#comment-17532968
]
Robert Scholte commented on MNG-6806:
-
Personally I don't think it is worth it to backport it to Maven 3. Just keep in
mind my comment:
https://github.com/apache/maven/pull/689#issuecomment-1061640064
> Provide Maven BOM
> -
>
> Key: MNG-6806
> URL: https://issues.apache.org/jira/browse/MNG-6806
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.9.0-candidate, 4.0.0-alpha-1, 4.0.0
>
>
> Maven libraries should always have the same version to ensure they work as
> expected, hence the preferred way to manage that is with a bom.
> Let's introduce the {{maven-dependencies}}, a
> [bom|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies]
> for Maven dependencies. We will likely need the same for plugins.
> See https://www.baeldung.com/spring-maven-bom about how to write and use the
> bom.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MSHARED-1016) Transitive provided dependencies are not removed from collected dependency graph
[ https://issues.apache.org/jira/browse/MSHARED-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528033#comment-17528033 ] Robert Scholte commented on MSHARED-1016: - [~cstamas] is quite active with this topic lately, so I'd prefer him to have a look at it and judge if your assumption is correct. You should consider to add a test to confirm this fix and to prevent regression in the future. > Transitive provided dependencies are not removed from collected dependency > graph > > > Key: MSHARED-1016 > URL: https://issues.apache.org/jira/browse/MSHARED-1016 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-3.1.0 >Reporter: Daniel Norberg >Priority: Major > > DependencyCollectorBuilder#collectDependencyGraph returns a dependency graph > containing transitive provided scope dependencies. This is inconsistent with > Maven behavior, which removes transitive provided scope dependencies from the > dependency graph: > [https://github.com/apache/maven/blob/706d9319f14b507f3c3deeba4eeda1a51a531c9b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java#L80|https://github.com/apache/maven/blob/706d9319f14b507f3c3deeba4eeda1a51a531c9b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemUtils.java#L80.] > This might be the root cause of > https://issues.apache.org/jira/browse/MENFORCER-402 and > https://issues.apache.org/jira/browse/MENFORCER-394 > Note that transitive test scope dependencies are correctly filtered out using > a dependency selector. > It seems to me that we can add another dependency selector to also filter out > transitive provided scope dependencies: > [https://github.com/apache/maven-dependency-tree/blob/7a1a12533ac6898fcb3dacbcf2466ef71d11c43a/src/main/java/org/apache/maven/shared/dependency/graph/internal/Maven31DependencyCollectorBuilder.java#L108|https://github.com/apache/maven-dependency-tree/blob/master/src/main/java/org/apache/maven/shared/dependency/graph/internal/Maven31DependencyCollectorBuilder.java#L108] > [https://github.com/apache/maven-dependency-tree/blob/7a1a12533ac6898fcb3dacbcf2466ef71d11c43a/src/main/java/org/apache/maven/shared/dependency/graph/internal/Maven3DependencyCollectorBuilder.java#L108] > I have submitted a PR to do this: > [https://github.com/apache/maven-dependency-tree/pull/9] > > > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MCOMPILER-489) User property for multiReleaseOutput
[ https://issues.apache.org/jira/browse/MCOMPILER-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517887#comment-17517887 ] Robert Scholte commented on MCOMPILER-489: -- AFAIK there's no IDE that supports this. Key issue is that it must be able to set the "release" value + JDK per sourcedirectory, whereas now it can only be set per project. > User property for multiReleaseOutput > > > Key: MCOMPILER-489 > URL: https://issues.apache.org/jira/browse/MCOMPILER-489 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: John Patrick >Priority: Minor > Labels: CompilerOptions > > Add support so multiReleaseOutput can be provided as a user property. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MCOMPILER-489) User property for multiReleaseOutput
[ https://issues.apache.org/jira/browse/MCOMPILER-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516515#comment-17516515 ] Robert Scholte commented on MCOMPILER-489: -- This would turn the parameter into a variable(adjustable via commandline) and that doesn't make sense to me. In case of multirelease in general you need to execute the compiler multiple times. I would expect once for Java 8 where multiReleaseOutput is false, for the others it must be true. > User property for multiReleaseOutput > > > Key: MCOMPILER-489 > URL: https://issues.apache.org/jira/browse/MCOMPILER-489 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: John Patrick >Priority: Minor > Labels: CompilerOptions > > Add support so multiReleaseOutput can be provided as a user property. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-6981) --project-list should also include its (child) modules
[
https://issues.apache.org/jira/browse/MNG-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6981:
Summary: --project-list should also include its (child) modules (was:
--project-list should also includes its (child) modules)
> --project-list should also include its (child) modules
> --
>
> Key: MNG-6981
> URL: https://issues.apache.org/jira/browse/MNG-6981
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Knut Wannheden
>Assignee: Martin Kanters
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Since there is already a {{\--non-recursive}} option a new {{\--recursive}}
> option might be confusing, but let me explain my use case. I often use the
> {{-pl}} option and in a multi-module Maven project with more than just two
> "levels", I would like to be able to build a project (or set of projects)
> including all child-modules. This is, AFAIK, currently not possible and what
> I would like to use the new {{\--recursive}} (or similar) option for.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-6981) --project-list should also includes its (child) modules
[
https://issues.apache.org/jira/browse/MNG-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6981:
Summary: --project-list should also includes its (child) modules (was:
Project list also includes its (child) modules)
> --project-list should also includes its (child) modules
> ---
>
> Key: MNG-6981
> URL: https://issues.apache.org/jira/browse/MNG-6981
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Knut Wannheden
>Assignee: Martin Kanters
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Since there is already a {{\--non-recursive}} option a new {{\--recursive}}
> option might be confusing, but let me explain my use case. I often use the
> {{-pl}} option and in a multi-module Maven project with more than just two
> "levels", I would like to be able to build a project (or set of projects)
> including all child-modules. This is, AFAIK, currently not possible and what
> I would like to use the new {{\--recursive}} (or similar) option for.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1909) Support JUnit 5 reflection access by changing add-exports to add-opens
[
https://issues.apache.org/jira/browse/SUREFIRE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488935#comment-17488935
]
Robert Scholte commented on SUREFIRE-1909:
--
[~sor] is the test+jpms expert
> Support JUnit 5 reflection access by changing add-exports to add-opens
> --
>
> Key: SUREFIRE-1909
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1909
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Christian Kohlschütter
>Priority: Major
> Attachments: surefire-jpms-bug.tar.gz
>
>
> Testing JUnit 5 classes of a JPMS-enabled project with Surefire may fail if a
> test class (or, for example, an abstract test base class) is not declared
> "public". I'm seeing the following error:
>
> {code:java}
> java.lang.reflect.InaccessibleObjectException: Unable to make public static
> void some.package.SomeClass.setupClass() throws java.io.IOException
> accessible: module some.module does not "opens some.package" to unnamed
> module @754ba872{code}
> This could be fixed by adding the recommended "{{opens some.package}}" to the
> project's module-info.java, however that is undesirable since it changes the
> project's behavior beyond just unit testing. Adding a secondary "test-only"
> module-info.java is also counterproductive since not all IDEs support this,
> and these two files would have to be kept in sync, which is non-trivial.
> An easy fix would be to change the "{{--add-exports-}}" VM parameter that
> surefire adds automatically to "{{-}}{{add-opens}}" in
> {{maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ModularClasspathForkConfiguration.java}}
> This bug is particularly bad because PMD now specifically complains about
> junit5 classes marked as public instead of package-private; see
> [https://pmd.github.io/2021/05/29/PMD-6.35.0/]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1993) Failsafe fails to detect module dependencies
[
https://issues.apache.org/jira/browse/SUREFIRE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488712#comment-17488712
]
Robert Scholte commented on SUREFIRE-1993:
--
By default if a module consumes (uses) a services, its service providers are
not included. This makes sense for compilation: you're not interested in
implementation details.
However, for failsafe it makes sense to include these service providers. You
can achieve this by calling {{ResolvePathsRequest.setIncludeAllProviders( true
)}} (as already discovered by [~mthmulders])
> Failsafe fails to detect module dependencies
>
>
> Key: SUREFIRE-1993
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1993
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: Java 17
> Maven 4.0.0-alpha-SNAPSHOT and 3.8.4
>Reporter: Maarten Mulders
>Priority: Minor
> Attachments: reproducer.zip
>
>
> Please see the attached project. It has three Maven modules, each defining
> its own JPMS module. The *application* module depends on an interface from
> the *studentservice* module, and the implementation for that interface lives
> in {*}studentservice-provider{*}. The {{module-info.java}} for the
> *studentservice-provider* module declares the implementation of that
> interface.
> When you run the application using {{{}./manually.sh{}}}, it correctly loads
> the *studentservice-provider* module. When you run the IT, it does not.
> The application prints the module path to standard out.
> From the test script it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar
> studentservice-provider/target/studentservice-provider-1.jar{code}
> From the integration test, which starts the same application, it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar{code}
>
> Note how in the integration test the *studentservice-provider* is missing in
> the output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Reopened] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened MCOMPILER-414:
--
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Assignee: Robert Scholte
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-414.
Resolution: Duplicate
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Assignee: Robert Scholte
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-414.
Assignee: Robert Scholte
Resolution: Fixed
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Assignee: Robert Scholte
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MCOMPILER-413) Parameters does not work when only release is specified
[
https://issues.apache.org/jira/browse/MCOMPILER-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-413.
Fix Version/s: 3.9.0
Assignee: Robert Scholte
Resolution: Fixed
> Parameters does not work when only release is specified
> ---
>
> Key: MCOMPILER-413
> URL: https://issues.apache.org/jira/browse/MCOMPILER-413
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Arch Linux, OpenJDK 11.0.6.u10, Maven 3.6.3
>Reporter: Jiri Kraml
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.9.0
>
>
> Compiling a project with the following maven-compiler-plugin configuration
> does not produce parameter name metadata in the class files:
> {{<{color:#0033b3}configuration{color}>}}
> {{ <{color:#0033b3}release{color}>9}}
> {{
> <{color:#0033b3}parameters{color}>true}}
> {{}}
> I believe this is a mistake, because
> {{javac --release 9 -parameters Test.java}}
> will produce the metadata.
> This behavior is due to dependency
> {{org.codehaus.plexus:plexus-compiler-javac:2.8.4}}, where in
> {{org.codehaus.plexus.compiler.javac.JavacCompiler}}, line 312, the function
> {{isPreJava18}} is called. This function does not evaluate the release
> property, only source and compilerVersion.
> Available workarounds in {{pom.xml}} are additionally specifying {{source}}
> or explicitly specifying the {{-parameters}} parameter in the plugin
> configuration.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481623#comment-17481623
]
Robert Scholte commented on MCOMPILER-481:
--
{quote}Shouldn't we automatically add test dependencies coming from the pom in
module-path for test?{quote}
No, that would mean that for instance junit ends up on the modulepath, that
doesn't make sense.
Only jars that are used by both compile and test should be added to the
modulepath.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480394#comment-17480394
]
Robert Scholte commented on MCOMPILER-481:
--
As I read it, it can only happen with test-compile. It looks like that only
need the includeStatic option, and plexus-java needs to make sure it will
include them static required modules, no matter the depth.
And there's the tricky part, as is it recursive code: direct static modules
should always be included, indirect static modules depend on this flag.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479986#comment-17479986
]
Robert Scholte commented on MCOMPILER-481:
--
Let's see what we'll get back from the compiler-dev list. The
[ResolvePathsRequest|https://github.com/codehaus-plexus/plexus-languages/blob/master/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/ResolvePathsRequest.java#L206-L210]
has an option to enforce extra modules, maybe we need to expose that as a
workaround.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479984#comment-17479984
]
Robert Scholte commented on MCOMPILER-481:
--
[~sbordet] smart to add those numbers :) I just don't understand the add-reads
is ignored in this case by the compiler.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-util-10.0.7.jar{}}}.
> In 3.9.0 this jar is missing from the module-path, causing the error.
> Attached you can find a reproducer: switch the
[jira] [Comment Edited] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479961#comment-17479961
]
Robert Scholte edited comment on MCOMPILER-481 at 1/21/22, 10:26 AM:
-
This is how I think it should work for compilation:
Based on the module descriptor:
- direct static required modules should always be included
- indirect required modules should always be included
- indirect static required modules should not be included
And I agree with [~sbordet]: it is very weird that {{--add-reads
compiler.bug.app=ALL-UNNAMED}} doesn't work.
To me the adjusted separation between 3.8.1 and 3.9.0 now looks better, maybe
we've now hit an issue in the compiler.
was (Author: rfscholte):
This is how I think it should work for compilation:
Based on the module descriptor:
- direct static required modules should always be included
- indirect required modules should always be included
- indirect static required modules should not be included
Based on the pom:
- every direct dependency should be added to the module path.
In this case the jetty-util-ajax should be added based on the last rule, but
(most likely) is removed because it is also an indirect required module. For an
unrelated dependency like junit it works as expected.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
>
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479961#comment-17479961
]
Robert Scholte commented on MCOMPILER-481:
--
This is how I think it should work for compilation:
Based on the module descriptor:
- direct static required modules should always be included
- indirect required modules should always be included
- indirect static required modules should not be included
Based on the pom:
- every direct dependency should be added to the module path.
In this case the jetty-util-ajax should be added based on the last rule, but
(most likely) is removed because it is also an indirect required module. For an
unrelated dependency like junit it works as expected.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478630#comment-17478630
]
Robert Scholte commented on MCOMPILER-481:
--
Found it, it was MJAVADOC-677 that required this change.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-util-10.0.7.jar{}}}.
> In 3.9.0 this jar is missing from the module-path, causing the error.
> Attached you can find a reproducer: switch the maven-compiler-plugin version
> from 3.8.1 (works) to 3.9.0 (does not
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478628#comment-17478628
]
Robert Scholte commented on MCOMPILER-481:
--
`ResolvePathsRequest.setIncludeStatic(true)` did fix it for me, still wondering
if this is the right approach.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.1
>
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-util-10.0.7.jar{}}}.
> In 3.9.0 this jar is missing from the module-path, causing the error.
> Attached you can find a reproducer: switch the
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access (requires static module not include anymore)
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478380#comment-17478380
]
Robert Scholte commented on MCOMPILER-481:
--
Based on the test, it is about supporting "static transitive", which is very
unusual but valid. I should have added a cross-link to the original issue in
one of the plugins.
> JPMS Regression: cannot access (requires static module not include
> anymore)
> ---
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Priority: Major
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-util-10.0.7.jar{}}}.
> In 3.9.0 this jar is missing from the module-path, causing the error.
> Attached you can find a reproducer: switch the maven-compiler-plugin
[jira] [Commented] (MCOMPILER-481) JPMS Regression: cannot access
[
https://issues.apache.org/jira/browse/MCOMPILER-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477436#comment-17477436
]
Robert Scholte commented on MCOMPILER-481:
--
Thanks for test-project, that really helps to understand the issue. The
handling of static required modules has changed a bit. I need some time to
figure out how we want to handle an optional dependencies in this way.
> JPMS Regression: cannot access
> --
>
> Key: MCOMPILER-481
> URL: https://issues.apache.org/jira/browse/MCOMPILER-481
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Simone Bordet
>Priority: Major
> Attachments: compiler-bug.tar.gz
>
>
> Version 3.8.1 is not affected.
> The problem lies in how the module-path is constructed by the
> maven-compiler-plugin – not sure what changes from 3.8.1 caused this.
> In 3.8.1:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> In 3.9.0:
> {code:java}
> -d
> /home/simon/tmp/compiler-bug/app/target/test-classes
> -classpath
> /home/simon/tmp/compiler-bug/app/target/test-classes
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util-ajax/10.0.7/jetty-util-ajax-10.0.7.jar
>
> /home/simon/.m2/repository/org/eclipse/jetty/jetty-util/10.0.7/jetty-util-10.0.7.jar
>
> /home/simon/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha5/slf4j-api-2.0.0-alpha5.jar
>
> /home/simon/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.8.2/junit-jupiter-api-5.8.2.jar
>
> /home/simon/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
>
> /home/simon/.m2/repository/org/junit/platform/junit-platform-commons/1.8.2/junit-platform-commons-1.8.2.jar
>
> /home/simon/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
>
> --module-path
> /home/simon/tmp/compiler-bug/app/target/classes
>
> /home/simon/.m2/repository/org/example/compiler-bug-service/1.0-SNAPSHOT/compiler-bug-service-1.0-SNAPSHOT.jar
>
> -sourcepath
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> -s
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
> -g
> -nowarn
> --release
> 11
> -encoding
> UTF-8
> --patch-module
> compiler.bug.app=/home/simon/tmp/compiler-bug/app/target/classes
> /home/simon/tmp/compiler-bug/app/src/test/java
>
> /home/simon/tmp/compiler-bug/app/target/generated-test-sources/test-annotations
>
> --add-reads
> compiler.bug.app=ALL-UNNAMED {code}
> Running with 3.9.0 yields:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:testCompile
> (default-testCompile) on project compiler-bug-app: Compilation failure
> [ERROR]
> /home/simon/tmp/compiler-bug/app/src/test/java/org/test/app/MainTest.java:[12,38]
> cannot access org.eclipse.jetty.util.ajax.JSON
> [ERROR] class file for org.eclipse.jetty.util.ajax.JSON not found {code}
> Class {{JSON}} is in {{{}jetty-util-10.0.7.jar{}}}.
> In 3.9.0 this jar is missing from the module-path, causing the error.
> Attached you can find a reproducer: switch the maven-compiler-plugin version
> from 3.8.1 (works) to 3.9.0 (does not
[jira] [Closed] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
[
https://issues.apache.org/jira/browse/MJAVADOC-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-704.
---
Assignee: Robert Scholte
Resolution: Not A Problem
> Javadoc plugin does not respect jdkToolchain
>
>
> Key: MJAVADOC-704
> URL: https://issues.apache.org/jira/browse/MJAVADOC-704
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.1
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
>
> If I run the following using JDK 8:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.3.1
>
>
> attach-javadocs
>
> jar
>
>
>
> 11
>
>
>
>
> {code}
> I get:
> {code:java}
> [INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program
> Files\Java\jdk-11.0.2]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar
> (attach-javadocs) on project core: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
> [...]
> Caused by: java.lang.UnsupportedOperationException
> at
> org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
> (CmdModuleNameExtractor.java:46){code}
> If I run the same code using JDK 11 I get past this point (I get an error
> relating to the contents of module-info):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
> module not found: org.slf4j
> [ERROR] requires org.slf4j;
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C ""C:\Program
> Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1] {code}
> This seems to imply that {{jdkToolchain}} is being ignored.
> On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin
> it seems to work just fine. My toolchains.xml file contains:
> {code:java}
>
>
>
> jdk
>
> 11
> oracle
>
>
> C:\Program Files\Java\jdk-11.0.2
>
>
> {code}
> Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
[
https://issues.apache.org/jira/browse/MJAVADOC-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477298#comment-17477298
]
Robert Scholte commented on MJAVADOC-704:
-
Make sure you're using the most recent version of JDK 11, otherwise you're
hitting the JDK-8208269. 11.0.2 is too old.
> Javadoc plugin does not respect jdkToolchain
>
>
> Key: MJAVADOC-704
> URL: https://issues.apache.org/jira/browse/MJAVADOC-704
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
>
> If I run the following using JDK 8:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.3.1
>
>
> attach-javadocs
>
> jar
>
>
>
> 11
>
>
>
>
> {code}
> I get:
> {code:java}
> [INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program
> Files\Java\jdk-11.0.2]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar
> (attach-javadocs) on project core: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
> [...]
> Caused by: java.lang.UnsupportedOperationException
> at
> org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
> (CmdModuleNameExtractor.java:46){code}
> If I run the same code using JDK 11 I get past this point (I get an error
> relating to the contents of module-info):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
> module not found: org.slf4j
> [ERROR] requires org.slf4j;
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C ""C:\Program
> Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1] {code}
> This seems to imply that {{jdkToolchain}} is being ignored.
> On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin
> it seems to work just fine. My toolchains.xml file contains:
> {code:java}
>
>
>
> jdk
>
> 11
> oracle
>
>
> C:\Program Files\Java\jdk-11.0.2
>
>
> {code}
> Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
[
https://issues.apache.org/jira/browse/MJAVADOC-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477277#comment-17477277
]
Robert Scholte edited comment on MJAVADOC-704 at 1/17/22, 3:29 PM:
---
https://github.com/apache/maven-javadoc-plugin/commit/ee4132f9d0f6f412784e108305524cf3b3a3009a
shows it works as expected.
Or is the IT incomplete?
was (Author: rfscholte):
https://github.com/apache/maven-javadoc-plugin/commit/ee4132f9d0f6f412784e108305524cf3b3a3009a
shows it works as expected.
> Javadoc plugin does not respect jdkToolchain
>
>
> Key: MJAVADOC-704
> URL: https://issues.apache.org/jira/browse/MJAVADOC-704
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
>
> If I run the following using JDK 8:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.3.1
>
>
> attach-javadocs
>
> jar
>
>
>
> 11
>
>
>
>
> {code}
> I get:
> {code:java}
> [INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program
> Files\Java\jdk-11.0.2]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar
> (attach-javadocs) on project core: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
> [...]
> Caused by: java.lang.UnsupportedOperationException
> at
> org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
> (CmdModuleNameExtractor.java:46){code}
> If I run the same code using JDK 11 I get past this point (I get an error
> relating to the contents of module-info):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
> module not found: org.slf4j
> [ERROR] requires org.slf4j;
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C ""C:\Program
> Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1] {code}
> This seems to imply that {{jdkToolchain}} is being ignored.
> On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin
> it seems to work just fine. My toolchains.xml file contains:
> {code:java}
>
>
>
> jdk
>
> 11
> oracle
>
>
> C:\Program Files\Java\jdk-11.0.2
>
>
> {code}
> Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-704) Javadoc plugin does not respect jdkToolchain
[
https://issues.apache.org/jira/browse/MJAVADOC-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477277#comment-17477277
]
Robert Scholte commented on MJAVADOC-704:
-
https://github.com/apache/maven-javadoc-plugin/commit/ee4132f9d0f6f412784e108305524cf3b3a3009a
shows it works as expected.
> Javadoc plugin does not respect jdkToolchain
>
>
> Key: MJAVADOC-704
> URL: https://issues.apache.org/jira/browse/MJAVADOC-704
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
>
> If I run the following using JDK 8:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.3.1
>
>
> attach-javadocs
>
> jar
>
>
>
> 11
>
>
>
>
> {code}
> I get:
> {code:java}
> [INFO] Toolchain in maven-javadoc-plugin: JDK[C:\Program
> Files\Java\jdk-11.0.2]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar
> (attach-javadocs) on project core: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar failed.
> [...]
> Caused by: java.lang.UnsupportedOperationException
> at
> org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor.getModuleName
> (CmdModuleNameExtractor.java:46){code}
> If I run the same code using JDK 11 I get past this point (I get an error
> relating to the contents of module-info):
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 -
> C:\Users\Gili\Documents\pouch\core\src\main\java\module-info.java:3: error:
> module not found: org.slf4j
> [ERROR] requires org.slf4j;
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C ""C:\Program
> Files\Java\jdk-11.0.2\bin\javadoc.exe" @options @argfile"
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'C:\Users\Gili\Documents\pouch\core\target\apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1] {code}
> This seems to imply that {{jdkToolchain}} is being ignored.
> On the other hand, if I use {{jdkToolchain}} with the maven-compiler-plugin
> it seems to work just fine. My toolchains.xml file contains:
> {code:java}
>
>
>
> jdk
>
> 11
> oracle
>
>
> C:\Program Files\Java\jdk-11.0.2
>
>
> {code}
> Am I doing anything wrong? Or is this a possible bug in the plugin?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7386) ModelMerger$MergingList is not serializable
[
https://issues.apache.org/jira/browse/MNG-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472288#comment-17472288
]
Robert Scholte commented on MNG-7386:
-
AFAIK creating new ArrayLists over and over again is kind of expensive. Would
be nice if it could be done once.
> ModelMerger$MergingList is not serializable
> ---
>
> Key: MNG-7386
> URL: https://issues.apache.org/jira/browse/MNG-7386
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.4
>Reporter: Kostiantyn Liutovych
>Priority: Minor
>
> Hello!
> [Spotless Maven plugin|https://github.com/diffplug/spotless] serializes
> {{org.apache.maven.model.Plugin}} instances to fingerprint plugin's
> configuration. Serialization fails for Maven 3.6.3 with:
> {code}
> java.io.NotSerializableException:
> org.apache.maven.model.merge.ModelMerger$MergingList
> {code}
> when plugin configuration comes from {{pluginManagement}}. Class
> {{org.apache.maven.model.Plugin}} implements {{java.io.Serializable}},
> however nested class {{org.apache.maven.model.merge.ModelMerger$MergingList}}
> does not.
> Would it be possible to make {{MergingList}} serializable or make
> {{Plugin#dependencies}} field always hold a serializable collection?
> Related issue for the Spotless Maven plugin:
> https://github.com/diffplug/spotless/issues/1073 and PR with a workaround
> https://github.com/diffplug/spotless/pull/1074.
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7362) DefaultArtifactResolver has spurious "Failure detected" INFO log
[
https://issues.apache.org/jira/browse/MNG-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472082#comment-17472082
]
Robert Scholte commented on MNG-7362:
-
So here's the weird thing: even though it is in the (maven2) compat jar, it is
frankly still being used. But yes, I expect this jar to be removed and that is
has been replaced with something else (that might have the same issue?)
> DefaultArtifactResolver has spurious "Failure detected" INFO log
>
>
> Key: MNG-7362
> URL: https://issues.apache.org/jira/browse/MNG-7362
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Frederic Lionello
>Priority: Major
> Fix For: wontfix-candidate
>
>
> The DefaultArtifactResolver may issue an INFO log "Failure detected.",
> without any additional context.
> This log was introduced in the changes of for MNG-6057 (see below for the
> file change and context) and, being an INFO message with "Failure" text, does
> seem like a debug leftover. On occasions, a maven command will display this
> log message while still being successful, leaving users wondering what has
> really happened.
> {code:java}
> $ git show 51cc76c32625be2f807dcf2ffbeb085984729b57
> maven-compat/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java
> commit 51cc76c32625be2f807dcf2ffbeb085984729b57
> Author: Karl Heinz Marbaise
> Date: Tue Sep 29 11:46:48 2015 +0200 [MNG-6090] CI friendly properties
> break submodule builds
> [MNG-6057] Problem with CI friendly usage of ${..} reactor order is
> changed
> o Based on the missing replacement of the versions ${revision}
> ${changelist} or ${sha1} within the parent element the order
> of the reactor changes.
> [MNG-5895] Problem with CI friendly usage of ${..} which is already
> defined via property in pom file.diff --git
> a/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java
>
> b/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java
> index fc154cb8a..915ee725f 100644
> ---
> a/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java
> +++
> b/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java
> @@ -376,7 +376,7 @@ public ArtifactResolutionResult resolve(
> ArtifactResolutionRequest request )
> ArtifactFilter resolutionFilter = request.getResolutionFilter();
> RepositorySystemSession session = getSession(
> request.getLocalRepository() );- // TODO hack because metadata isn't
> generated in m2e correctly and i want to run the maven i have in the
> + // TODO: hack because metadata isn't generated in m2e correctly and
> i want to run the maven i have in the
> // workspace
> if ( source == null )
> {
> @@ -506,6 +506,7 @@ public ArtifactResolutionResult resolve(
> ArtifactResolutionRequest request )
> if ( result.hasMetadataResolutionExceptions() ||
> result.hasVersionRangeViolations()
> || result.hasCircularDependencyExceptions() )
> {
> + logger.info( "Failure detected." );
> return result;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7372) Maven should display version info in case of error
[ https://issues.apache.org/jira/browse/MNG-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464613#comment-17464613 ] Robert Scholte commented on MNG-7372: - I think everybody benefits if the right information is provided ASAP. The lazy developer just copy/paste section X, we don't have to ask to provide other basic information. Other things that might be interesting: refer to the issue-tracker of the plugin, maybe even provide the plugin configuration in case a plugin is causing the issue. But let's start with the proper version information. > Maven should display version info in case of error > -- > > Key: MNG-7372 > URL: https://issues.apache.org/jira/browse/MNG-7372 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Minor > > On Stack Overflow you see quite often a Java related error in Maven and next > they show the output of `java -version`. > If `JAVA_HOME` was used, then the output of `java -version` is useless and > could lead to false assumptions. > In case of an Exception, the output of `mvn -v` should be added to console > logging. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MNG-7372) Maven should display version info in case of error
Robert Scholte created MNG-7372: --- Summary: Maven should display version info in case of error Key: MNG-7372 URL: https://issues.apache.org/jira/browse/MNG-7372 Project: Maven Issue Type: Improvement Reporter: Robert Scholte On Stack Overflow you see quite often a Java related error in Maven and next they show the output of `java -version`. If `JAVA_HOME` was used, then the output of `java -version` is useless and could lead to false assumptions. In case of an Exception, the output of `mvn -v` should be added to console logging. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7369) Maven BOM doesn't need to package as a JAR
[
https://issues.apache.org/jira/browse/MNG-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-7369:
Labels: must-be-in-4.0.0-alpha-1 up-for-grabs (was: good-first-issue
must-be-in-4.0.0-alpha-1)
> Maven BOM doesn't need to package as a JAR
> --
>
> Key: MNG-7369
> URL: https://issues.apache.org/jira/browse/MNG-7369
> Project: Maven
> Issue Type: Task
> Components: General
>Reporter: Maarten Mulders
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1, up-for-grabs
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The new Maven BOM module packages as a JAR file, which is almost empty:
> {code}
> $ unzip -l maven-bom/target/maven-bom-4.0.0-alpha-1-SNAPSHOT.jar
> Archive: maven-bom/target/maven-bom-4.0.0-alpha-1-SNAPSHOT.jar
> Length DateTimeName
> - -- -
> 358 01-26-2020 09:04 META-INF/MANIFEST.MF
> 0 01-26-2020 09:04 META-INF/
> 0 01-26-2020 09:04 META-INF/maven/
> 0 01-26-2020 09:04 META-INF/maven/org.apache.maven/
> 0 01-26-2020 09:04 META-INF/maven/org.apache.maven/maven-bom/
> 272 01-26-2020 09:04 META-INF/DEPENDENCIES
> 11358 01-26-2020 09:04 META-INF/LICENSE
> 179 01-26-2020 09:04 META-INF/NOTICE
> 6260 01-26-2020 09:04
> META-INF/maven/org.apache.maven/maven-bom/pom.xml
>77 01-26-2020 09:04
> META-INF/maven/org.apache.maven/maven-bom/pom.properties
> - ---
> 18504 10 files
> {code}
> The Maven BOM module should package as "pom" to avoid this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-2478) add "resources-filtered" filtered resource directories to super POM
[
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462282#comment-17462282
]
Robert Scholte commented on MNG-2478:
-
Think about scope! Maven 3.8.2+ learned the scope was too big and as you know:
I'm only having a focus on Maven 4.
> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.9.0-candidate
>
>
> The super POM contains default folders for resources that are NOT filtered
> (src/main/resources and src/test/resources). If one (additionally) needs a
> filtered resources folder, it needs to override the default and therefore has
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the
> super POM. This should also fit to the philosophy of maven that aims to have
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make
> things more obvious to the user maybe "resources-filtered" would be better.
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>
> src/main/resources
>
>
>
> src/main/resources-filtered
> true
>
>
>
>
>
> src/test/resources
>
>
>
> src/test/resources-filtered
> true
>
>
> {code}
> Update: The folder name has been changed to "resources-filtered".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MNG-7360) Can't parse project that has tag in plugin configuration
[
https://issues.apache.org/jira/browse/MNG-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-7360:
---
Assignee: Guillaume Nodet
> Can't parse project that has tag in plugin configuration
> -
>
> Key: MNG-7360
> URL: https://issues.apache.org/jira/browse/MNG-7360
> Project: Maven
> Issue Type: Bug
> Components: build/consumer
>Affects Versions: 4.0.x-candidate
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (3a06530dbce82e2054afa3cc4c81631910474bd0)
> Maven home:
> /usr/local/Cellar/maven-snapshot/4.0.0-alpha-1-SNAPSHOT_290/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Maarten Mulders
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: Screenshot 2021-12-13 at 13.45.01.png
>
>
> The Apache Camel project has the following snippet in their root POM:
> {code:xml}
>
> org.codehaus.mojo
> flatten-maven-plugin
> 1.2.5
>
>
> default-cli
> process-resources
>
> flatten
>
>
>
>
>
> expand
>
>
>
>
>
>
> {code}
> With Maven 4's "Build Consumer" feature enabled, parsing this plugin
> definition breaks with
> {code:none}
> [INFO] BuildTimeEventSpy is registered.
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Unable to transform pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project (/Users/maarten/Code/open-source/camel/pom.xml) has 1
> error
> [ERROR] Unable to transform pom: Not a regular file:
> /Users/maarten/Code/open-source/pom.xml
> [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 verbose output
> [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/ProjectBuildingException
> {code}
> I suspect that the {{}} tag is the culprit. It seems to me that it
> causes the {{ParentXMLFilter}} to think it needs to do its work. The attached
> screenshot shows the stacktrace that brought me to this idea. As the
> {{BufferingParser}} class processes its buffer of events, it encounters a
> situation of an "end {{parent}} tag". But that {{parent}} tag did not have
> child elements {{version}} and {{relativePath}} and so, it decides it needs
> to resolve the parent as {{../pom.xml}} against the project path
> ({{/Users/maarten/Code/open-source/camel/}} in my case), leading to the
> non-existing path of {{/Users/maarten/Code/open-source/pom.xml}}.
> I think the bug here is not that it resolves to a non-existing path (it's
> good to check that before actually reading the file). I think the bug is that
> the {{ParentXMLFilter}} is acting on the {{parent}} tag inside the plugin
> configuration.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7360) Can't parse project that has tag in plugin configuration
[
https://issues.apache.org/jira/browse/MNG-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458395#comment-17458395
]
Robert Scholte commented on MNG-7360:
-
Looks like the FastForwardFilter doesn't do its job properly anymore.
> Can't parse project that has tag in plugin configuration
> -
>
> Key: MNG-7360
> URL: https://issues.apache.org/jira/browse/MNG-7360
> Project: Maven
> Issue Type: Bug
> Components: build/consumer
>Affects Versions: 4.0.x-candidate
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (3a06530dbce82e2054afa3cc4c81631910474bd0)
> Maven home:
> /usr/local/Cellar/maven-snapshot/4.0.0-alpha-1-SNAPSHOT_290/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Maarten Mulders
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: Screenshot 2021-12-13 at 13.45.01.png
>
>
> The Apache Camel project has the following snippet in their root POM:
> {code:xml}
>
> org.codehaus.mojo
> flatten-maven-plugin
> 1.2.5
>
>
> default-cli
> process-resources
>
> flatten
>
>
>
>
>
> expand
>
>
>
>
>
>
> {code}
> With Maven 4's "Build Consumer" feature enabled, parsing this plugin
> definition breaks with
> {code:none}
> [INFO] BuildTimeEventSpy is registered.
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Unable to transform pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project (/Users/maarten/Code/open-source/camel/pom.xml) has 1
> error
> [ERROR] Unable to transform pom: Not a regular file:
> /Users/maarten/Code/open-source/pom.xml
> [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 verbose output
> [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/ProjectBuildingException
> {code}
> I suspect that the {{}} tag is the culprit. It seems to me that it
> causes the {{ParentXMLFilter}} to think it needs to do its work. The attached
> screenshot shows the stacktrace that brought me to this idea. As the
> {{BufferingParser}} class processes its buffer of events, it encounters a
> situation of an "end {{parent}} tag". But that {{parent}} tag did not have
> child elements {{version}} and {{relativePath}} and so, it decides it needs
> to resolve the parent as {{../pom.xml}} against the project path
> ({{/Users/maarten/Code/open-source/camel/}} in my case), leading to the
> non-existing path of {{/Users/maarten/Code/open-source/pom.xml}}.
> I think the bug here is not that it resolves to a non-existing path (it's
> good to check that before actually reading the file). I think the bug is that
> the {{ParentXMLFilter}} is acting on the {{parent}} tag inside the plugin
> configuration.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MWRAPPER-35) don't copy mvnwDebug* scripts by default
[ https://issues.apache.org/jira/browse/MWRAPPER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457598#comment-17457598 ] Robert Scholte commented on MWRAPPER-35: I don't agree with this change. It is a great way to show there's something like mvnDebug, is seems one of the most underestimated features of Maven. It is up to the caller of wrapper:wrapper to decide if these files should be committed. > don't copy mvnwDebug* scripts by default > > > Key: MWRAPPER-35 > URL: https://issues.apache.org/jira/browse/MWRAPPER-35 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Plugin >Affects Versions: 3.1.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > in MWRAPPER-28, we added mvnwDebug scripts, which are useful to be able to > debug Maven when the build has an issue > this seems like a exceptional case, that most projects won't really need: > providing these scripts by default seems overkill > then changing the default to not copy these scripts gives probably a better > classical user experience -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MSCRIPTING-8) Support scriptResource
[ https://issues.apache.org/jira/browse/MSCRIPTING-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte resolved MSCRIPTING-8. - Fix Version/s: 3.0.1 Resolution: Fixed Fixed in [028a9003433ade64782ab9c13ae5c679f003f3e3|https://gitbox.apache.org/repos/asf?p=maven-scripting-plugin.git;a=commit;h=028a9003433ade64782ab9c13ae5c679f003f3e3] > Support scriptResource > -- > > Key: MSCRIPTING-8 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-8 > Project: Maven Scripting > Issue Type: New Feature >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.1 > > > In case of shared scripts (in jars), it would be handy to refer to that > resource, otherwise one must unpack that dependency first before referring to > the file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MSCRIPTING-5) Links on about page not working
[ https://issues.apache.org/jira/browse/MSCRIPTING-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte resolved MSCRIPTING-5. - Fix Version/s: 3.0.1 Assignee: Robert Scholte Resolution: Fixed Fixed in [02e462130d300ef04aba10d4d5cd01c217621fab|https://gitbox.apache.org/repos/asf?p=maven-scripting-plugin.git;a=commit;h=02e462130d300ef04aba10d4d5cd01c217621fab] > Links on about page not working > --- > > Key: MSCRIPTING-5 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-5 > Project: Maven Scripting > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Andreas Holtz >Assignee: Robert Scholte >Priority: Minor > Labels: documentation > Fix For: 3.0.1 > > > Most links on About page > ([https://maven.apache.org/plugins/maven-scripting-plugin/index.html)] are > not working: > * usage page - > https://maven.apache.org/plugins/maven-scripting-plugin/usage.html > * mailing list - > https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html > * FAQ - [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] > * mail archive - > [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] > * issue tracking - > [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] > * source repository - > [https://maven.apache.org/plugins/maven-scripting-plugin/source-repository.html] > all point to "Page not found". -- This message was sent by Atlassian Jira (v8.20.1#820001)
