[jira] [Assigned] (MDEP-757) bug with "non-test scoped test only dependencies found"
[
https://issues.apache.org/jira/browse/MDEP-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen reassigned MDEP-757:
---
Assignee: Henning Schmiedehausen
> bug with "non-test scoped test only dependencies found"
> ---
>
> Key: MDEP-757
> URL: https://issues.apache.org/jira/browse/MDEP-757
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: mvn --version
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 11.0.11, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
>
> Starting with 3.2.0, I see this problem in one of my project modules:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
> foundation ---
> [WARNING] Non-test scoped test only dependencies found:
> [WARNING] com.fasterxml.jackson.core:jackson-databind:jar:2.12.2:compile
> {noformat}
> This is not correct:
> {noformat}
> % cd lib/foundation
> % grep -r databind src/main
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/WriteableLocator.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/DataDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ImmutableDataObject.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> {noformat}
> So this dependency is used all over the place in the main sources (which is
> why it can not be in test scope). However, the plugin no longer (it did in
> 3.1.2) recognize it (all the uses are just annotations, so I guess that is
> the problem) and raises this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-757) bug with "non-test scoped test only dependencies found"
[
https://issues.apache.org/jira/browse/MDEP-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693803#comment-17693803
]
Henning Schmiedehausen commented on MDEP-757:
-
{{use true}}
> bug with "non-test scoped test only dependencies found"
> ---
>
> Key: MDEP-757
> URL: https://issues.apache.org/jira/browse/MDEP-757
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: mvn --version
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 11.0.11, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
>
> Starting with 3.2.0, I see this problem in one of my project modules:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
> foundation ---
> [WARNING] Non-test scoped test only dependencies found:
> [WARNING] com.fasterxml.jackson.core:jackson-databind:jar:2.12.2:compile
> {noformat}
> This is not correct:
> {noformat}
> % cd lib/foundation
> % grep -r databind src/main
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/WriteableLocator.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/DataDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ImmutableDataObject.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> {noformat}
> So this dependency is used all over the place in the main sources (which is
> why it can not be in test scope). However, the plugin no longer (it did in
> 3.1.2) recognize it (all the uses are just annotations, so I guess that is
> the problem) and raises this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-757) bug with "non-test scoped test only dependencies found"
[
https://issues.apache.org/jira/browse/MDEP-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701873#comment-17701873
]
Henning Schmiedehausen commented on MDEP-757:
-
you are most likely correct but you need to convince the maintainers of the
plugin and the dependency analyzer library that they are not which in my
experience is an uphill battle.
Setting the ignoreAllNonTestScoped flag and moving on with life was my answer
to that.
> bug with "non-test scoped test only dependencies found"
> ---
>
> Key: MDEP-757
> URL: https://issues.apache.org/jira/browse/MDEP-757
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: mvn --version
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 11.0.11, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Attachments: MDEP-757-reproducer-2-rec.zip
>
>
> Starting with 3.2.0, I see this problem in one of my project modules:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
> foundation ---
> [WARNING] Non-test scoped test only dependencies found:
> [WARNING] com.fasterxml.jackson.core:jackson-databind:jar:2.12.2:compile
> {noformat}
> This is not correct:
> {noformat}
> % cd lib/foundation
> % grep -r databind src/main
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/WriteableLocator.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/DataDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ImmutableDataObject.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> {noformat}
> So this dependency is used all over the place in the main sources (which is
> why it can not be in test scope). However, the plugin no longer (it did in
> 3.1.2) recognize it (all the uses are just annotations, so I guess that is
> the problem) and raises this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-757) bug with "non-test scoped test only dependencies found"
[
https://issues.apache.org/jira/browse/MDEP-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701889#comment-17701889
]
Henning Schmiedehausen commented on MDEP-757:
-
Good luck. I root for you.
> bug with "non-test scoped test only dependencies found"
> ---
>
> Key: MDEP-757
> URL: https://issues.apache.org/jira/browse/MDEP-757
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: mvn --version
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 11.0.11, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Attachments: MDEP-757-reproducer-2-rec.zip
>
>
> Starting with 3.2.0, I see this problem in one of my project modules:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
> foundation ---
> [WARNING] Non-test scoped test only dependencies found:
> [WARNING] com.fasterxml.jackson.core:jackson-databind:jar:2.12.2:compile
> {noformat}
> This is not correct:
> {noformat}
> % cd lib/foundation
> % grep -r databind src/main
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/WriteableLocator.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/DataDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ImmutableDataObject.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> {noformat}
> So this dependency is used all over the place in the main sources (which is
> why it can not be in test scope). However, the plugin no longer (it did in
> 3.1.2) recognize it (all the uses are just annotations, so I guess that is
> the problem) and raises this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MDEP-757) bug with "non-test scoped test only dependencies found"
[
https://issues.apache.org/jira/browse/MDEP-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen reassigned MDEP-757:
---
Assignee: (was: Henning Schmiedehausen)
> bug with "non-test scoped test only dependencies found"
> ---
>
> Key: MDEP-757
> URL: https://issues.apache.org/jira/browse/MDEP-757
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: mvn --version
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 11.0.11, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Priority: Major
> Attachments: MDEP-757-reproducer-2-rec.zip
>
>
> Starting with 3.2.0, I see this problem in one of my project modules:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
> foundation ---
> [WARNING] Non-test scoped test only dependencies found:
> [WARNING] com.fasterxml.jackson.core:jackson-databind:jar:2.12.2:compile
> {noformat}
> This is not correct:
> {noformat}
> % cd lib/foundation
> % grep -r databind src/main
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/WriteableLocator.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/DataDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ImmutableDataObject.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> {noformat}
> So this dependency is used all over the place in the main sources (which is
> why it can not be in test scope). However, the plugin no longer (it did in
> 3.1.2) recognize it (all the uses are just annotations, so I guess that is
> the problem) and raises this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-757) bug with "non-test scoped test only dependencies found"
[
https://issues.apache.org/jira/browse/MDEP-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711681#comment-17711681
]
Henning Schmiedehausen commented on MDEP-757:
-
I unassigned myself. I have no further plans to work on this.
> bug with "non-test scoped test only dependencies found"
> ---
>
> Key: MDEP-757
> URL: https://issues.apache.org/jira/browse/MDEP-757
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: mvn --version
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 11.0.11, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Priority: Major
> Attachments: MDEP-757-reproducer-2-rec.zip
>
>
> Starting with 3.2.0, I see this problem in one of my project modules:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.2.0:analyze-only (basepom.default) @
> foundation ---
> [WARNING] Non-test scoped test only dependencies found:
> [WARNING] com.fasterxml.jackson.core:jackson-databind:jar:2.12.2:compile
> {noformat}
> This is not correct:
> {noformat}
> % cd lib/foundation
> % grep -r databind src/main
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/DataSet.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/WriteableLocator.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectMetadata.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/DataDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectAttribute.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonDeserialize;
> src/main/java/dev/data/ObjectDefinition.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> src/main/java/dev/data/ImmutableDataObject.java:import
> com.fasterxml.jackson.databind.annotation.JsonSerialize;
> {noformat}
> So this dependency is used all over the place in the main sources (which is
> why it can not be in test scope). However, the plugin no longer (it did in
> 3.1.2) recognize it (all the uses are just annotations, so I guess that is
> the problem) and raises this error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MINVOKER-317) invoker:install installs different sets of dependencies, depending on the reactor build
Henning Schmiedehausen created MINVOKER-317:
---
Summary: invoker:install installs different sets of dependencies,
depending on the reactor build
Key: MINVOKER-317
URL: https://issues.apache.org/jira/browse/MINVOKER-317
Project: Maven Invoker Plugin
Issue Type: Bug
Affects Versions: 3.4.0, 3.3.0
Reporter: Henning Schmiedehausen
- Clone this repository: [https://github.com/hgschmie/invoker-bug]
- Run "mvn clean install"
The repository builds, runs all integration tests and installs dependencies
successfully.
- Now run "mvn -pl :test clean install"
One of the integration tests fails. The error message in
test/target/it/test-it-fails/build.log is
[ERROR] Failed to execute goal on project test-it-ok: Could not resolve
dependencies for project invoker-bug:test-it-ok:jar:0.1-SNAPSHOT: Could not
find artifact invoker-bug:dep:jar:tests:0.1-SNAPSHOT -> [Help 1]
- Now run "mvn -am -pl :test clean install"
the integration tests succeed
The main difference is:
For the failing build, invoker:install reports
{quote}[INFO] --- maven-invoker-plugin:3.4.0:install
(basepom.invoker-integration-testing.default) @ test ---
[WARNING] skip dependencyProject null for projectId=invoker-bug:dep:0.1-SNAPSHOT
[INFO] Installing /Users/henning/scratch/invoker-bug/pom.xml to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/parent/0.1-SNAPSHOT/parent-0.1-SNAPSHOT.pom
[INFO] Installing /Users/henning/scratch/invoker-bug/test/pom.xml to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT.pom
[INFO] Installing
/Users/henning/scratch/invoker-bug/test/target/test-0.1-SNAPSHOT.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/test/target/test-0.1-SNAPSHOT-tests.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT-tests.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/test/target/test-0.1-SNAPSHOT-sources.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT-sources.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/test/target/test-0.1-SNAPSHOT-test-sources.jar
to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT-test-sources.jar
{quote}
For the successful build, it reports
{quote}[INFO] --- maven-invoker-plugin:3.4.0:install
(basepom.invoker-integration-testing.default) @ test ---
[INFO] Installing /Users/henning/scratch/invoker-bug/dep/pom.xml to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/dep/0.1-SNAPSHOT/dep-0.1-SNAPSHOT.pom
[INFO] Installing
/Users/henning/scratch/invoker-bug/dep/target/dep-0.1-SNAPSHOT.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/dep/0.1-SNAPSHOT/dep-0.1-SNAPSHOT.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/dep/target/dep-0.1-SNAPSHOT-tests.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/dep/0.1-SNAPSHOT/dep-0.1-SNAPSHOT-tests.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/dep/target/dep-0.1-SNAPSHOT-sources.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/dep/0.1-SNAPSHOT/dep-0.1-SNAPSHOT-sources.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/dep/target/dep-0.1-SNAPSHOT-test-sources.jar
to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/dep/0.1-SNAPSHOT/dep-0.1-SNAPSHOT-test-sources.jar
[INFO] Installing /Users/henning/scratch/invoker-bug/pom.xml to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/parent/0.1-SNAPSHOT/parent-0.1-SNAPSHOT.pom
[INFO] Installing /Users/henning/scratch/invoker-bug/test/pom.xml to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT.pom
[INFO] Installing
/Users/henning/scratch/invoker-bug/test/target/test-0.1-SNAPSHOT.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/test/target/test-0.1-SNAPSHOT-tests.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT-tests.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/test/target/test-0.1-SNAPSHOT-sources.jar to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT-sources.jar
[INFO] Installing
/Users/henning/scratch/invoker-bug/test/target/test-0.1-SNAPSHOT-test-sources.jar
to
/Users/henning/scratch/invoker-bug/test/target/local-repo/invoker-bug/test/0.1-SNAPSHOT/test-0.1-SNAPSHOT-test-sources.jar
{quote}
So the s
[jira] [Created] (MINVOKER-318) invoker install can not resolve test dependencies if they overlap with runtime deps
Henning Schmiedehausen created MINVOKER-318: --- Summary: invoker install can not resolve test dependencies if they overlap with runtime deps Key: MINVOKER-318 URL: https://issues.apache.org/jira/browse/MINVOKER-318 Project: Maven Invoker Plugin Issue Type: Bug Affects Versions: 3.4.0 Reporter: Henning Schmiedehausen invoker:install can not install a test dependencies (e.g. a tests jar) if the main artifact is requested in runtime scope. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-368) Parameter 'localRepository' is deprecated
[
https://issues.apache.org/jira/browse/MPMD-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718155#comment-17718155
]
Henning Schmiedehausen commented on MPMD-368:
-
This is a constant pain for our integration builds as this is the only plugin
right now that reports this problem. Any update on a fix (not just a
workaround)?
> Parameter 'localRepository' is deprecated
> -
>
> Key: MPMD-368
> URL: https://issues.apache.org/jira/browse/MPMD-368
> Project: Maven PMD Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> Probably since Maven 3.9.1 this warning is seen in builds:
> [WARNING] Parameter 'localRepository' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to '${repositorySystemSession}' expression and get LRM from it instead.
> This broke the CI and has been worked around (MPMD-367) but the root cause
> should be addressed. This same issue might appear in other plugins as well
> and break their CIs that check to see there are no warnings in a build.
> I'm not sure whether this can be fixed without breaking compatibility with
> older Maven versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-368) Parameter 'localRepository' is deprecated
[
https://issues.apache.org/jira/browse/MPMD-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722643#comment-17722643
]
Henning Schmiedehausen commented on MPMD-368:
-
The build tool throwing warnings fails CI builds in a lot of organizations (it
does so in mine and in previous places that I worked). It may not fail at the
actual tool level but the CI harness detects warnings and fails the build.
Upgrading the tools in the tool chain is independent from the actual code.
Often the code developers don't even have control over the build pipeline or
the tools that are used. Having a build suddenly throw warnings that are
completely unrelated to the code itself but because of the combination of build
tool and build plugins without any actionable advice *and* doing so in a patch
level change is problematic from my PoV.
> Parameter 'localRepository' is deprecated
> -
>
> Key: MPMD-368
> URL: https://issues.apache.org/jira/browse/MPMD-368
> Project: Maven PMD Plugin
> Issue Type: Bug
>Affects Versions: 3.20.0, 3.21.0
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> Probably since Maven 3.9.1 this warning is seen in builds:
> [WARNING] Parameter 'localRepository' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to '${repositorySystemSession}' expression and get LRM from it instead.
> This broke the CI and has been worked around (MPMD-367) but the root cause
> should be addressed. This same issue might appear in other plugins as well
> and break their CIs that check to see there are no warnings in a build.
> I'm not sure whether this can be fixed without breaking compatibility with
> older Maven versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRELEASE-1129) https POM URIs break the release plugin
Henning Schmiedehausen created MRELEASE-1129: Summary: https POM URIs break the release plugin Key: MRELEASE-1129 URL: https://issues.apache.org/jira/browse/MRELEASE-1129 Project: Maven Release Plugin Issue Type: Bug Components: prepare Affects Versions: 3.0.1 Reporter: Henning Schmiedehausen replacing the "http" URIs with "https" in the POM headers breaks the release process. When the pom gets prepared, the plugin rewrites the header back to "http" and adds an xmlns section to every opening tag in the POM creating an invalid POM. Sadly we are stuck with http:// URIs in the POMs for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1129) https POM URIs break the release plugin
[ https://issues.apache.org/jira/browse/MRELEASE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729463#comment-17729463 ] Henning Schmiedehausen commented on MRELEASE-1129: -- this refers to the URIs in the "project" element of the POM (xmlns, xmlns:xsi and xsi:schemaLocation). > https POM URIs break the release plugin > --- > > Key: MRELEASE-1129 > URL: https://issues.apache.org/jira/browse/MRELEASE-1129 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 3.0.1 >Reporter: Henning Schmiedehausen >Priority: Major > > replacing the "http" URIs with "https" in the POM headers breaks the release > process. > When the pom gets prepared, the plugin rewrites the header back to "http" and > adds an xmlns section to every opening tag in the POM creating an invalid POM. > Sadly we are stuck with http:// URIs in the POMs for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRELEASE-1129) https POM URIs break the release plugin
[ https://issues.apache.org/jira/browse/MRELEASE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MRELEASE-1129: - Attachment: pom.xml > https POM URIs break the release plugin > --- > > Key: MRELEASE-1129 > URL: https://issues.apache.org/jira/browse/MRELEASE-1129 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 3.0.1 >Reporter: Henning Schmiedehausen >Priority: Major > Fix For: waiting-for-feedback, wontfix-candidate > > Attachments: pom.xml > > > replacing the "http" URIs with "https" in the POM headers breaks the release > process. > When the pom gets prepared, the plugin rewrites the header back to "http" and > adds an xmlns section to every opening tag in the POM creating an invalid POM. > Sadly we are stuck with http:// URIs in the POMs for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1129) https POM URIs break the release plugin
[ https://issues.apache.org/jira/browse/MRELEASE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729531#comment-17729531 ] Henning Schmiedehausen commented on MRELEASE-1129: -- looking at your analysis and comparing with reality, this looks invalid to me. drop the pom.xml file into a folder. Run mvn release:prepare. Receive the second pom. > https POM URIs break the release plugin > --- > > Key: MRELEASE-1129 > URL: https://issues.apache.org/jira/browse/MRELEASE-1129 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 3.0.1 >Reporter: Henning Schmiedehausen >Priority: Major > Fix For: waiting-for-feedback, wontfix-candidate > > Attachments: pom.xml > > > replacing the "http" URIs with "https" in the POM headers breaks the release > process. > When the pom gets prepared, the plugin rewrites the header back to "http" and > adds an xmlns section to every opening tag in the POM creating an invalid POM. > Sadly we are stuck with http:// URIs in the POMs for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRELEASE-1129) https POM URIs break the release plugin
[ https://issues.apache.org/jira/browse/MRELEASE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MRELEASE-1129: - Attachment: pom-after-transform.xml > https POM URIs break the release plugin > --- > > Key: MRELEASE-1129 > URL: https://issues.apache.org/jira/browse/MRELEASE-1129 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 3.0.1 >Reporter: Henning Schmiedehausen >Priority: Major > Fix For: waiting-for-feedback, wontfix-candidate > > Attachments: pom-after-transform.xml, pom.xml > > > replacing the "http" URIs with "https" in the POM headers breaks the release > process. > When the pom gets prepared, the plugin rewrites the header back to "http" and > adds an xmlns section to every opening tag in the POM creating an invalid POM. > Sadly we are stuck with http:// URIs in the POMs for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1129) https POM xmlns URIs break the release plugin
[
https://issues.apache.org/jira/browse/MRELEASE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17730808#comment-17730808
]
Henning Schmiedehausen commented on MRELEASE-1129:
--
Herve: My understanding is that the "default" maven namespace identifier is
"{{http://maven.apache.org/POM/4.0.0}}"; for the root (unnamed) namespace in the
pom XML file. That namespace is mapped onto the schema with the
xsi:schemaLocation="https://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd"; declaration. This maps the
"{{http://maven.apache.org/POM/4.0.0}}"; namespace identifier to the
"{{https://maven.apache.org/xsd/maven-4.0.0.xsd}}"; schema location. In XML
terms, this is just convention. There is nothing magical to the string
"http://maven.apache.org/POM/4.0.0";, literally its only requirement is that it
is a URI, at least according to the XML spec. Is there a hard requirement
somewhere documented that the root namespace identifier must be the
"http://maven.apache.org/POM/4.0.0"; URI ?
This works fine btw:
{{https://foo.bar.baz";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="https://foo.bar.baz
https://maven.apache.org/xsd/maven-4.0.0.xsd";>}}
The release plugin however does this:
https://github.com/apache/maven-release/blame/f744036d62a550d321b157ed547bf21f586ec065/maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModelETL.java#L186-L198
So it does not inspect the pom for existing namespace declarations and
mappings. As a result, the code overwrites the root namespace, but then finds
an exisiting xsi:schemaLocation attribute, assumes that "this definition will
contain the root namespace definition. But it does not. It only contains the
"https://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd";. What the code *should do* is, in
case the tag exists to load it, and *add* the new definition, so that the
resulting project tag looks like this:
{{http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="https://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd";>
}}
now it would write the new pom correctly (the XML writer would no longer
qualify the nested tags with the namespace identifier because it was able to
resolve the namespace to a schema.
so an "else" branch here:
https://github.com/apache/maven-release/blame/f744036d62a550d321b157ed547bf21f586ec065/maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModelETL.java#L198
is needed that loads the attribute, parses the namespace identifier/schema
pairs, checks whether the newly created `"http://maven.apache.org/POM/"; +
modelVersion` namespace identifier is in there and if not *add* it to the
existing definition.
And *that* is the bug in the code. Overwriting the root namespace identifier is
rude and should not happen in the first place, *but* if the code insists on
doing so, then it should at least write the schema locations correctly. And it
does not do that today.
[~michael-o] I am not sure how you came to the conclusion that "the supplied
input is broken". Can you explain that reasoning?
> https POM xmlns URIs break the release plugin
> -
>
> Key: MRELEASE-1129
> URL: https://issues.apache.org/jira/browse/MRELEASE-1129
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.1
>Reporter: Henning Schmiedehausen
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: pom-after-transform.xml, pom.xml
>
>
> replacing the "http" URIs with "https" in the POM headers breaks the release
> process.
> When the pom gets prepared, the plugin rewrites the header back to "http" and
> adds an xmlns section to every opening tag in the POM creating an invalid POM.
> Sadly we are stuck with http:// URIs in the POMs for now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1129) https POM xmlns URIs break the release plugin
[ https://issues.apache.org/jira/browse/MRELEASE-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731300#comment-17731300 ] Henning Schmiedehausen commented on MRELEASE-1129: -- [~elharo] Thanks for the explanation. This is much more useful than a toxic "shit in, shit out" comment. I feel maven should in that case fail at pom loading time if the root namespace identifier is not the expected (or one of the expected in the future) values. The fact that most of maven works with the pom example I gave (basically everything but releasing) makes me wonder how many invalid poms are out there. > https POM xmlns URIs break the release plugin > - > > Key: MRELEASE-1129 > URL: https://issues.apache.org/jira/browse/MRELEASE-1129 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 3.0.1 >Reporter: Henning Schmiedehausen >Priority: Major > Attachments: pom-after-transform.xml, pom.xml > > > replacing the "http" URIs with "https" in the POM headers breaks the release > process. > When the pom gets prepared, the plugin rewrites the header back to "http" and > adds an xmlns section to every opening tag in the POM creating an invalid POM. > Sadly we are stuck with http:// URIs in the POMs for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJAVADOC-752) Setting the output directory affects dependencySourceIncludes
Henning Schmiedehausen created MJAVADOC-752:
---
Summary: Setting the output directory affects
dependencySourceIncludes
Key: MJAVADOC-752
URL: https://issues.apache.org/jira/browse/MJAVADOC-752
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.5.0
Reporter: Henning Schmiedehausen
I have a large, multi-module build (github.com/jdbi/jdbi) where we build
separate javadoc jars for all modules. These are built with a javadoc plugin
configuration that writes the javadoc information into target/apidocs. This
works fine.
At the end of our build we aggregate all the separate javadoc modules into a
single documentation site.
This is the javadoc configuration for that:
{{
${project.build.directory}/generated-docs/apidocs
true
org.jdbi:*
Jdbi3 ${project.version} API
Jdbi3 ${project.version} API
}}
The reactor build tries to load the included modules (org.jdbi:*) but does not
look into the target/apidocs folder where the javadoc was written but from
target/generated-docs/apidocs. Setting the output directory for the aggregation
module affects the directory that the javadoc plugin uses to resolve the
dependencySourceInclude directory.
Expected effect: Setting the output directory only affects the place where the
aggregated doc is written. The plugin still picks up the existing javadoc from
the target/apidocs folders in the included modules
Observed effect: Setting the output directory makes the plugin look at the
wrong folders for the included moduled and does not find the existing
documentation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-752) Setting the output directory affects dependencySourceIncludes
[
https://issues.apache.org/jira/browse/MJAVADOC-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-752:
Component/s: javadoc
(was: jar)
> Setting the output directory affects dependencySourceIncludes
> -
>
> Key: MJAVADOC-752
> URL: https://issues.apache.org/jira/browse/MJAVADOC-752
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> I have a large, multi-module build (github.com/jdbi/jdbi) where we build
> separate javadoc jars for all modules. These are built with a javadoc plugin
> configuration that writes the javadoc information into target/apidocs. This
> works fine.
> At the end of our build we aggregate all the separate javadoc modules into a
> single documentation site.
> This is the javadoc configuration for that:
> {{
>
> ${project.build.directory}/generated-docs/apidocs
> true
>
> org.jdbi:*
>
> Jdbi3 ${project.version} API
> Jdbi3 ${project.version} API
>
> }}
> The reactor build tries to load the included modules (org.jdbi:*) but does
> not look into the target/apidocs folder where the javadoc was written but
> from target/generated-docs/apidocs. Setting the output directory for the
> aggregation module affects the directory that the javadoc plugin uses to
> resolve the dependencySourceInclude directory.
> Expected effect: Setting the output directory only affects the place where
> the aggregated doc is written. The plugin still picks up the existing javadoc
> from the target/apidocs folders in the included modules
> Observed effect: Setting the output directory makes the plugin look at the
> wrong folders for the included moduled and does not find the existing
> documentation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-753) javadoc plugin does not find sources in auto-module when creating docs
Henning Schmiedehausen created MJAVADOC-753:
---
Summary: javadoc plugin does not find sources in auto-module when
creating docs
Key: MJAVADOC-753
URL: https://issues.apache.org/jira/browse/MJAVADOC-753
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.5.0
Reporter: Henning Schmiedehausen
clone this repo: [https://github.com/hgschmie/javadoc-bug]
run "mvn clean install"
expected outcome: builds a project, generates a javadoc jar
observed outcome:
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (basepom.default) on
project javadoc-bug: MavenReportException: Error while generating Javadoc:}}
{{[ERROR] Exit code: 1}}
{{[ERROR]
/Users/henning/oss/bugs/javadoc/src/main/java/maven/bugs/internal/InternalImportBindingBuilder.java:7:
error: cannot access Provider}}
{{[ERROR] static final class InternalBindingProvider implements
Provider {}}
{{[ERROR] ^}}
{{[ERROR] class file for javax.inject.Provider not found}}
{{[ERROR] 1 error}}
{{[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages}}
Setting the release to "8" works (but loses the module information)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-767) javadoc creates invalid --patch-module statements
Henning Schmiedehausen created MJAVADOC-767:
---
Summary: javadoc creates invalid --patch-module statements
Key: MJAVADOC-767
URL: https://issues.apache.org/jira/browse/MJAVADOC-767
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.5.0
Reporter: Henning Schmiedehausen
Jdbi is a mixed Java/Kotlin multi-module project. We aggregate a final jar that
contains all the javadocs for all modules in a doc step. This works ok for
non-JPMS (Java 8 target).
When introducing JPMS into our project, the javadoc plugin starts adding
--patch-module options like this:
{{--patch-module
org.jdbi.v3.caffeine='/Users/henning/code/jdbi/cache/caffeine-cache/src/main/java:/Users/henning/code/jdbi/cache/caffeine-cache/target/generated-sources/annotations'
}}
However, in our configuration, we exclude the kotlin specific modules:
{quote}
maven-javadoc-plugin
javadoc-jar
jar
package
true
false
org.jdbi:*
org.jdbi:jdbi3-kotlin
org.jdbi:jdbi3-kotlin-sqlobject
jdbi3-kotlin,jdbi3-kotlin-sqlobject
Jdbi3 ${project.version} API
Jdbi3 ${project.version} API
{quote}
which results in the maven-javadoc-plugin creating command line options like
this:
{{--patch-module org.jdbi.v3.kotlin=
}}
which in turn crash the javadoc command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-767) javadoc creates invalid --patch-module statements
[
https://issues.apache.org/jira/browse/MJAVADOC-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-767:
Description:
Jdbi is a mixed Java/Kotlin multi-module project. We aggregate a final jar that
contains all the javadocs for all modules in a doc step. This works ok for
non-JPMS (Java 8 target).
When introducing JPMS into our project, the javadoc plugin starts adding
--patch-module options like this:
{{--patch-module
org.jdbi.v3.caffeine='/Users/henning/code/jdbi/cache/caffeine-cache/src/main/java:/Users/henning/code/jdbi/cache/caffeine-cache/target/generated-sources/annotations'}}
However, in our configuration, we exclude the kotlin specific modules:
{code:xml}
maven-javadoc-plugin
javadoc-jar
jar
package
true
false
org.jdbi:*
org.jdbi:jdbi3-kotlin
org.jdbi:jdbi3-kotlin-sqlobject
jdbi3-kotlin,jdbi3-kotlin-sqlobject
Jdbi3 ${project.version} API
Jdbi3 ${project.version} API
{code}
which results in the maven-javadoc-plugin creating command line options like
this:
{{--patch-module org.jdbi.v3.kotlin=}}
which in turn crash the javadoc command.
was:
Jdbi is a mixed Java/Kotlin multi-module project. We aggregate a final jar that
contains all the javadocs for all modules in a doc step. This works ok for
non-JPMS (Java 8 target).
When introducing JPMS into our project, the javadoc plugin starts adding
--patch-module options like this:
{{--patch-module
org.jdbi.v3.caffeine='/Users/henning/code/jdbi/cache/caffeine-cache/src/main/java:/Users/henning/code/jdbi/cache/caffeine-cache/target/generated-sources/annotations'
}}
However, in our configuration, we exclude the kotlin specific modules:
{quote}
maven-javadoc-plugin
javadoc-jar
jar
package
true
false
org.jdbi:*
org.jdbi:jdbi3-kotlin
org.jdbi:jdbi3-kotlin-sqlobject
jdbi3-kotlin,jdbi3-kotlin-sqlobject
Jdbi3 ${project.version} API
Jdbi3 ${project.version} API
{quote}
which results in the maven-javadoc-plugin creating command line options like
this:
{{--patch-module org.jdbi.v3.kotlin=
}}
which in turn crash the javadoc command.
> javadoc creates invalid --patch-module statements
> -
>
> Key: MJAVADOC-767
> URL: https://issues.apache.org/jira/browse/MJAVADOC-767
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> Jdbi is a mixed Java/Kotlin multi-module project. We aggregate a final jar
> that contains all the javadocs for all modules in a doc step. This works ok
> for non-JPMS (Java 8 target).
> When introducing JPMS into our project, the javadoc plugin starts adding
> --patch-module options like this:
> {{--patch-module
> org.jdbi.v3.caffeine='/Users/henning/code/jdbi/cache/caffeine-cache/src/main/java:/Users/henning/code/jdbi/cache/caffeine-cache/target/generated-sources/annotations'}}
> However, in our configuration, we exclude the kotlin specific modules:
> {code:xml}
>
> maven-javadoc-plugin
>
>
> javadoc-jar
>
> jar
>
> package
>
> true
> false
>
>
> org.jdbi:*
>
>
>
> org.jdbi:jdbi3-kotlin
>
> org.jdbi:jdbi3-kotlin-sqlobject
>
>
> jdbi3-kotlin,jdbi3-kotlin-sqlobject
> Jdbi3 ${project.version} API
> Jdbi3 ${project.version} API
>
>
>
>
> {code}
> which results in the maven-javadoc-plugin creating command line options like
> this:
> {{--patch-module org.jdbi.v3.kotlin=}}
> which in turn crash the javadoc command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-768) javadoc has a hard time with JPMS and provided or optional module dependencies.
Henning Schmiedehausen created MJAVADOC-768: --- Summary: javadoc has a hard time with JPMS and provided or optional module dependencies. Key: MJAVADOC-768 URL: https://issues.apache.org/jira/browse/MJAVADOC-768 Project: Maven Javadoc Plugin Issue Type: Bug Components: jar, javadoc Affects Versions: 3.5.0 Reporter: Henning Schmiedehausen Check out this project: [https://github.com/hgschmie/mjavadoc768/] run `mvn clean install` in the root. This results in this error: ``` [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:aggregate-jar (javadoc-jar) on project doc: MavenReportException: Error while generating Javadoc: [ERROR] Exit code: 1 [ERROR] /Users/henning/scratch/jdbug/thing2/src/main/java/module-info.java:4: error: module not found: jakarta.annotation [ERROR] requires static jakarta.annotation; [ERROR] ^ [ERROR] /Users/henning/scratch/jdbug/thing1/src/main/java/module-info.java:4: error: module not found: jakarta.annotation [ERROR] requires static jakarta.annotation; [ERROR] ^ [ERROR] 2 errors [ERROR] Command line was: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc -J-Xmx1024m @options @packages @argfile [ERROR] [ERROR] Refer to the generated Javadoc files in '/Users/henning/scratch/jdbug/doc/target/apidocs' dir. ``` The problem is that both maven modules (thing1 and thing2) declare a compile time dependency on "jakarta-annotation" using either maven `provided` scope or maven `optional`. This is reflected in the JPMS module descriptor by using `required static jakarta.annotation;`. But the javadoc tool, when it wants to generate the aggregation jar, generates an options file that does not contain the jakarta-annotation jar on the module path (which is needed for javadoc to succeed), so the tool reports the error above. The javadoc tool needs to add all provided and optional dependencies to the module path for the aggregated jar. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-768) javadoc has a hard time with JPMS and provided or optional module dependencies.
[
https://issues.apache.org/jira/browse/MJAVADOC-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-768:
Description:
Check out this project: [https://github.com/hgschmie/mjavadoc768/]
run {{mvn clean install}} in the root. This results in this error:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:aggregate-jar (javadoc-jar)
on project doc: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1
[ERROR] /Users/henning/scratch/jdbug/thing2/src/main/java/module-info.java:4:
error: module not found: jakarta.annotation
[ERROR] requires static jakarta.annotation;
[ERROR] ^
[ERROR] /Users/henning/scratch/jdbug/thing1/src/main/java/module-info.java:4:
error: module not found: jakarta.annotation
[ERROR] requires static jakarta.annotation;
[ERROR] ^
[ERROR] 2 errors
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages @argfile
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/Users/henning/scratch/jdbug/doc/target/apidocs' dir.
{code}
The problem is that both maven modules (thing1 and thing2) declare a compile
time dependency on "jakarta-annotation" using either maven {{provided}} scope
or maven {{optional}}. This is reflected in the JPMS module descriptor by using
`required static jakarta.annotation;`.
But the javadoc tool, when it wants to generate the aggregation jar, generates
an options file that does not contain the jakarta-annotation jar on the module
path (which is needed for javadoc to succeed), so the tool reports the error
above. The javadoc tool needs to add all provided and optional dependencies to
the module path for the aggregated jar.
was:
Check out this project: [https://github.com/hgschmie/mjavadoc768/]
run `mvn clean install` in the root. This results in this error:
```
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:aggregate-jar (javadoc-jar)
on project doc: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1
[ERROR] /Users/henning/scratch/jdbug/thing2/src/main/java/module-info.java:4:
error: module not found: jakarta.annotation
[ERROR] requires static jakarta.annotation;
[ERROR] ^
[ERROR] /Users/henning/scratch/jdbug/thing1/src/main/java/module-info.java:4:
error: module not found: jakarta.annotation
[ERROR] requires static jakarta.annotation;
[ERROR] ^
[ERROR] 2 errors
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages @argfile
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/Users/henning/scratch/jdbug/doc/target/apidocs' dir.
```
The problem is that both maven modules (thing1 and thing2) declare a compile
time dependency on "jakarta-annotation" using either maven `provided` scope or
maven `optional`. This is reflected in the JPMS module descriptor by using
`required static jakarta.annotation;`.
But the javadoc tool, when it wants to generate the aggregation jar, generates
an options file that does not contain the jakarta-annotation jar on the module
path (which is needed for javadoc to succeed), so the tool reports the error
above. The javadoc tool needs to add all provided and optional dependencies to
the module path for the aggregated jar.
> javadoc has a hard time with JPMS and provided or optional module
> dependencies.
> ---
>
> Key: MJAVADOC-768
> URL: https://issues.apache.org/jira/browse/MJAVADOC-768
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> Check out this project: [https://github.com/hgschmie/mjavadoc768/]
> run {{mvn clean install}} in the root. This results in this error:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:aggregate-jar
> (javadoc-jar) on project doc: MavenReportException: Error while generating
> Javadoc:
> [ERROR] Exit code: 1
> [ERROR] /Users/henning/scratch/jdbug/thing2/src/main/java/module-info.java:4:
> error: module not found: jakarta.annotation
> [ERROR] requires static jakarta.annotation;
> [ERROR] ^
> [ERROR] /Users/henning/scratch/jdbug/thing1/src/main/java/module-info.java:4:
> error: module not found: jakarta.annotation
> [ERROR] requires static jakarta.annotation;
> [ERROR] ^
> [ERROR] 2 errors
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
[jira] [Created] (SUREFIRE-2190) optional dependencies and JPMS modules confuse surefire
Henning Schmiedehausen created SUREFIRE-2190:
Summary: optional dependencies and JPMS modules confuse surefire
Key: SUREFIRE-2190
URL: https://issues.apache.org/jira/browse/SUREFIRE-2190
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support, Maven Surefire Plugin
Affects Versions: 3.1.2
Reporter: Henning Schmiedehausen
The surefire plugin, when executing tests for JPMS code, patches the test code
"into" the module under test (using {{--patch-module}}). This work for
compile+runtime dependencies (`requires`) but not for compile required/runtime
optional dependencies ({{requires static}}).
The plugin only adds the module under test using {{--module
module.under.test.id}} to the JVM that is executing the test classes. As
{{requires static}} dependencies are not loaded transitively, any dependency
that is optional for the main artifact but required for test code is not found.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2190) optional dependencies and JPMS modules confuse surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated SUREFIRE-2190:
-
Description:
The surefire plugin, when executing tests for JPMS code, patches the test code
"into" the module under test (using {{{}--patch-module{}}}). This work for
compile+runtime dependencies (`requires`) but not for compile required/runtime
optional dependencies ({{{}requires static{}}}).
The plugin only adds the module under test using {{--add-modules
module.under.test.id}} to the JVM that is executing the test classes. As
{{requires static}} dependencies are not loaded transitively, any dependency
that is optional for the main artifact but required for test code is not found.
clone and build the test repo: [https://github.com/hgschmie/msurefire2190]
This repo contains three artifacts with identical code:
thing1 builds a main artifact without JPMS
thing2 builds a main artifact with a strong ({{{}requires{}}}) dependency on
jakarta.annotation.
thing3 builds a main artifact with a compile-only ({{requires static}})
dependency on jakarta.annotation.
The code and its test classes are otherwise identical.
Running {{mvn -DskipTests}} clean install builds all three modules and the test
code.
Running {{mvn surefire:test}} passes the tests in the first two modules but
fails in the third.
Explanation:
The surefire plugin, when it executes tests using JPMS adds all referenced
modules to the module path (in this case the module under test itself and the
jakarta.annotations-api jar). It then adds the main module using
{{--add-modules}} and patches this module with the test classes (using
{{{}-patch-module{}}}, so that the test classes execute as part of the module.
In case of a compile+runtime ({{requires}}) relationship, the JVM will find the
required JPMS module on the module path and add it as accessible. This is why
the "thing2" tests pass.
In case of a compile only/runtime optional ({{requires static}}) relationship,
the JVM will not add the module transitively as it is considered a
compilation-only dependency. For the code under test to be able to access the
classes from jakarta.annotation, they must be declared as a module. However,
the test code only adds the module under test with {{--add-modules}}. So the
test classes do not find any classes from the jakarta.annotation module and the
test fails.
The fix is simple: Instead of just adding the module under test using
{{--add-modules}}, the surefire plugin should use {{-add-modules
ALL-MODULE-PATH}}.
Which is correct, because the code is not looking for compile time only
dependencies but actual runtime dependencies where the code under execution may
also need to access optional runtime dependencies (see
[https://nipafx.dev/java-modules-optional-dependencies/] for a slightly longer
explanation).
was:
The surefire plugin, when executing tests for JPMS code, patches the test code
"into" the module under test (using {{--patch-module}}). This work for
compile+runtime dependencies (`requires`) but not for compile required/runtime
optional dependencies ({{requires static}}).
The plugin only adds the module under test using {{--module
module.under.test.id}} to the JVM that is executing the test classes. As
{{requires static}} dependencies are not loaded transitively, any dependency
that is optional for the main artifact but required for test code is not found.
> optional dependencies and JPMS modules confuse surefire
> ---
>
> Key: SUREFIRE-2190
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2190
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.1.2
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> The surefire plugin, when executing tests for JPMS code, patches the test
> code "into" the module under test (using {{{}--patch-module{}}}). This work
> for compile+runtime dependencies (`requires`) but not for compile
> required/runtime optional dependencies ({{{}requires static{}}}).
> The plugin only adds the module under test using {{--add-modules
> module.under.test.id}} to the JVM that is executing the test classes. As
> {{requires static}} dependencies are not loaded transitively, any dependency
> that is optional for the main artifact but required for test code is not
> found.
> clone and build the test repo: [https://github.com/hgschmie/msurefire2190]
> This repo contains three artifacts with identical code:
> thing1 builds a main artifact without JPMS
> thing2 builds a main artifact with a strong ({{{}requires{}}}) dependency on
> jakarta.annotation.
> thing3 builds a main artifact with a compile-only ({{requires static}})
> dependency on jakarta.annotati
[jira] [Created] (SUREFIRE-2191) surefire crashes on a JPMS modularized project that uses junit5
Henning Schmiedehausen created SUREFIRE-2191:
Summary: surefire crashes on a JPMS modularized project that uses
junit5
Key: SUREFIRE-2191
URL: https://issues.apache.org/jira/browse/SUREFIRE-2191
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support, process forking
Affects Versions: 3.1.2
Reporter: Henning Schmiedehausen
clone this repository: [https://github.com/hgschmie/surefire-2191
|https://github.com/hgschmie/surefire-2191] and build it.
The build fails during testing with a large and cryptic error description. The
code only uses the junit jupiter APIs and imports the with {{ requires
transitive org.junit.jupiter.api;}}
This is the surefireargs file that the plugin creates:
{code}
--module-path
"/Users/henning/scratch/surefire-junit-bug/target/classes:/Users/henning/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.10.0/junit-jupiter-api-5.10.0.jar:/Users/henning/.m2/repository/org/opentest4j/opentest4j/1.3.0/opentest4j-1.3.0.jar:/Users/henning/.m2/repository/org/junit/platform/junit-platform-commons/1.10.0/junit-platform-commons-1.10.0.jar:/Users/henning/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar"
--class-path
"/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-api/3.1.2/surefire-api-3.1.2.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-booter/3.1.2/surefire-booter-3.1.2.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-extensions-spi/3.1.2/surefire-extensions-spi-3.1.2.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.1.2/surefire-logger-api-3.1.2.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-shared-utils/3.1.2/surefire-shared-utils-3.1.2.jar:/Users/henning/scratch/surefire-junit-bug/target/test-classes:/Users/henning/.m2/repository/org/assertj/assertj-core/3.24.2/assertj-core-3.24.2.jar:/Users/henning/.m2/repository/net/bytebuddy/byte-buddy/1.12.21/byte-buddy-1.12.21.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-junit-platform/3.1.2/surefire-junit-platform-3.1.2.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/common-java5/3.1.2/common-java5-3.1.2.jar:/Users/henning/.m2/repository/org/junit/platform/junit-platform-launcher/1.10.0/junit-platform-launcher-1.10.0.jar:/Users/henning/.m2/repository/org/junit/platform/junit-platform-engine/1.10.0/junit-platform-engine-1.10.0.jar:/Users/henning/.m2/repository/org/junit/jupiter/junit-jupiter-engine/5.10.0/junit-jupiter-engine-5.10.0.jar"
--patch-module
surefire.junit.bug="/Users/henning/scratch/surefire-junit-bug/target/test-classes"
--add-opens
surefire.junit.bug/demo=ALL-UNNAMED
--add-modules
surefire.junit.bug
--add-reads
surefire.junit.bug=ALL-UNNAMED
org.apache.maven.surefire.booter.ForkedBooter
{code}
It is not clear to me on how to fix/mitigate this error. The same build works
fine without JPMS modules or with automatic versioned modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
Henning Schmiedehausen created MJAVADOC-769:
---
Summary: javadoc plugin can not deal with optional dependencies
when building java 9+ javadocs
Key: MJAVADOC-769
URL: https://issues.apache.org/jira/browse/MJAVADOC-769
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.5.0
Reporter: Henning Schmiedehausen
clone this repository: https://github.com/hgschmie/mjavadoc770
This builds an artifact, a tests artifact and a javadoc jar.
When building this for Java 9+ compatibility (javadoc generate a list of
modules) and using modules with Automatic-Module-Name enabled, the javadoc
plugin can not access the optional dependencies:
{code}
ERROR] Exit code: 1
[ERROR]
/Users/henning/scratch/mjavadoc770/src/main/java/mavenbugs/mjavadoc770/InternalImportBindingBuilder.java:88:
error: cannot access Provider
[ERROR] static final class InternalBindingProvider implements
Provider {
[ERROR] ^
[ERROR] class file for javax.inject.Provider not found
[ERROR] 1 error
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages
{code}
Note that all other plugins (compiler, surefire) work fine. Just the javadoc
plugin does not.
{code}
--add-modules
ALL-MODULE-PATH
--module-path
'/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc770/target/mjavadoc770-1.0-SNAPSHOT.jar'
--patch-module
mavenbugs.mjavadoc770='/Users/henning/scratch/mjavadoc770/src/main/java:/Users/henning/scratch/mjavadoc770/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
-encoding
'UTF-8'
-public
-quiet
--release
11
-bottom
'Copyright © 2023. All rights reserved.'
-charset
'UTF-8'
-d
'/Users/henning/scratch/mjavadoc770/target/apidocs'
-docencoding
'UTF-8'
-Xdoclint:none
-doctitle
'mjavadoc770 1.0-SNAPSHOT API'
-linkoffline
'https://docs.oracle.com/en/java/javase/11/docs/api'
'/Users/henning/scratch/mjavadoc770/target/javadoc-bundle-options'
-nohelp
-use
-version
-windowtitle
'mjavadoc770 1.0-SNAPSHOT API'
{code}
The javadoc plugin decides that the "javax.inject-1.jar" is added to the
classpath even though it is an optional dependency of the main module. Contrary
to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module path.
Neither of the modules is either an automatic (with an entry in
META-INF/MANIFEST.MF) nor a full JPMS module (module-info). The plugin decided
arbitrarily that one should go onto the class path and one onto the module path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-769:
Description:
clone this repository: https://github.com/hgschmie/mjavadoc769
This builds an artifact, a tests artifact and a javadoc jar.
When building this for Java 9+ compatibility (javadoc generate a list of
modules) and using modules with Automatic-Module-Name enabled, the javadoc
plugin can not access the optional dependencies:
{code}
ERROR] Exit code: 1
[ERROR]
/Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
error: cannot access Provider
[ERROR] static final class InternalBindingProvider implements
Provider {
[ERROR] ^
[ERROR] class file for javax.inject.Provider not found
[ERROR] 1 error
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages
{code}
Note that all other plugins (compiler, surefire) work fine. Just the javadoc
plugin does not.
{code}
--add-modules
ALL-MODULE-PATH
--module-path
'/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
--patch-module
mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
-encoding
'UTF-8'
-public
-quiet
--release
11
-bottom
'Copyright © 2023. All rights reserved.'
-charset
'UTF-8'
-d
'/Users/henning/scratch/mjavadoc769/target/apidocs'
-docencoding
'UTF-8'
-Xdoclint:none
-doctitle
'mjavadoc769 1.0-SNAPSHOT API'
-linkoffline
'https://docs.oracle.com/en/java/javase/11/docs/api'
'/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
-nohelp
-use
-version
-windowtitle
'mjavadoc769 1.0-SNAPSHOT API'
{code}
The javadoc plugin decides that the "javax.inject-1.jar" is added to the
classpath even though it is an optional dependency of the main module. Contrary
to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module path.
Neither of the modules is either an automatic (with an entry in
META-INF/MANIFEST.MF) nor a full JPMS module (module-info). The plugin decided
arbitrarily that one should go onto the class path and one onto the module path.
was:
clone this repository: https://github.com/hgschmie/mjavadoc770
This builds an artifact, a tests artifact and a javadoc jar.
When building this for Java 9+ compatibility (javadoc generate a list of
modules) and using modules with Automatic-Module-Name enabled, the javadoc
plugin can not access the optional dependencies:
{code}
ERROR] Exit code: 1
[ERROR]
/Users/henning/scratch/mjavadoc770/src/main/java/mavenbugs/mjavadoc770/InternalImportBindingBuilder.java:88:
error: cannot access Provider
[ERROR] static final class InternalBindingProvider implements
Provider {
[ERROR] ^
[ERROR] class file for javax.inject.Provider not found
[ERROR] 1 error
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages
{code}
Note that all other plugins (compiler, surefire) work fine. Just the javadoc
plugin does not.
{code}
--add-modules
ALL-MODULE-PATH
--module-path
'/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc770/target/mjavadoc770-1.0-SNAPSHOT.jar'
--patch-module
mavenbugs.mjavadoc770='/Users/henni
[jira] [Updated] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-769:
Description:
clone this repository: https://github.com/hgschmie/mjavadoc769
This builds an artifact, a tests artifact and a javadoc jar.
When building this for Java 9+ compatibility (javadoc generate a list of
modules) and using modules with Automatic-Module-Name enabled, the javadoc
plugin can not access the optional dependencies:
{code}
ERROR] Exit code: 1
[ERROR]
/Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
error: cannot access Provider
[ERROR] static final class InternalBindingProvider implements
Provider {
[ERROR] ^
[ERROR] class file for javax.inject.Provider not found
[ERROR] 1 error
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages
{code}
Note that all other plugins (compiler, surefire) work fine. Just the javadoc
plugin does not.
{code}
--add-modules
ALL-MODULE-PATH
--module-path
'/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
--patch-module
mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
-encoding
'UTF-8'
-public
-quiet
--release
11
-bottom
'Copyright © 2023. All rights reserved.'
-charset
'UTF-8'
-d
'/Users/henning/scratch/mjavadoc769/target/apidocs'
-docencoding
'UTF-8'
-Xdoclint:none
-doctitle
'mjavadoc769 1.0-SNAPSHOT API'
-linkoffline
'https://docs.oracle.com/en/java/javase/11/docs/api'
'/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
-nohelp
-use
-version
-windowtitle
'mjavadoc769 1.0-SNAPSHOT API'
{code}
The javadoc plugin decides that the "javax.inject-1.jar" is added to the
classpath even though it is an optional dependency of the main module. Contrary
to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module path.
The reason for this may be that the jakarta module contains a module-info
(hidden in META-INF/versions/9/) while the javax.inject jar does not.
was:
clone this repository: https://github.com/hgschmie/mjavadoc769
This builds an artifact, a tests artifact and a javadoc jar.
When building this for Java 9+ compatibility (javadoc generate a list of
modules) and using modules with Automatic-Module-Name enabled, the javadoc
plugin can not access the optional dependencies:
{code}
ERROR] Exit code: 1
[ERROR]
/Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
error: cannot access Provider
[ERROR] static final class InternalBindingProvider implements
Provider {
[ERROR] ^
[ERROR] class file for javax.inject.Provider not found
[ERROR] 1 error
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages
{code}
Note that all other plugins (compiler, surefire) work fine. Just the javadoc
plugin does not.
{code}
--add-modules
ALL-MODULE-PATH
--module-path
'/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
--patch-module
mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/g
[jira] [Updated] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-769:
Description:
clone this repository: https://github.com/hgschmie/mjavadoc769
This builds an artifact, a tests artifact and a javadoc jar.
When building this for Java 9+ compatibility (javadoc generate a list of
modules) and using modules with Automatic-Module-Name enabled, the javadoc
plugin can not access the optional dependencies:
{code}
ERROR] Exit code: 1
[ERROR]
/Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
error: cannot access Provider
[ERROR] static final class InternalBindingProvider implements
Provider {
[ERROR] ^
[ERROR] class file for javax.inject.Provider not found
[ERROR] 1 error
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages
{code}
Note that all other plugins (compiler, surefire) work fine. Just the javadoc
plugin does not.
{code}
--add-modules
ALL-MODULE-PATH
--module-path
'/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
--patch-module
mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
-encoding
'UTF-8'
-public
-quiet
--release
11
-bottom
'Copyright © 2023. All rights reserved.'
-charset
'UTF-8'
-d
'/Users/henning/scratch/mjavadoc769/target/apidocs'
-docencoding
'UTF-8'
-Xdoclint:none
-doctitle
'mjavadoc769 1.0-SNAPSHOT API'
-linkoffline
'https://docs.oracle.com/en/java/javase/11/docs/api'
'/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
-nohelp
-use
-version
-windowtitle
'mjavadoc769 1.0-SNAPSHOT API'
{code}
The javadoc plugin decides that the "javax.inject-1.jar" is added to the
classpath even though it is an optional dependency of the main module. Contrary
to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module path.
The reason for this may be that the jakarta module contains a module-info
(hidden in META-INF/versions/9/) while the javax.inject jar does not.
However, the checker-qual
(org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar) dependency
is put on the module path even though it does not contain a module-info file.
However, it contains an {{Automatic-Module-Name}} entry in META-INF/MANIFEST.
It seems that the javadoc plugin treats automatic dependencies with entry in
the manifest different from automatic dependencies determined by filename.
was:
clone this repository: https://github.com/hgschmie/mjavadoc769
This builds an artifact, a tests artifact and a javadoc jar.
When building this for Java 9+ compatibility (javadoc generate a list of
modules) and using modules with Automatic-Module-Name enabled, the javadoc
plugin can not access the optional dependencies:
{code}
ERROR] Exit code: 1
[ERROR]
/Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
error: cannot access Provider
[ERROR] static final class InternalBindingProvider implements
Provider {
[ERROR] ^
[ERROR] class file for javax.inject.Provider not found
[ERROR] 1 error
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages
{code}
Note that all other plugins (compiler, surefire) work fine. Just the javadoc
plugin does not.
{code}
--add-modules
ALL-MODULE-PATH
--module-path
'/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.
[jira] [Commented] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757065#comment-17757065
]
Henning Schmiedehausen commented on MJAVADOC-769:
-
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc plugin tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same was as module source FILENAME (iaw patched into the main
module).
> javadoc plugin can not deal with optional dependencies when building java 9+
> javadocs
> -
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
> -encoding
> 'UTF-8'
> -public
> -quiet
> --release
> 11
> -bottom
> 'Copyright © 2023. All rights reserved.'
> -charset
> 'UTF-8'
> -d
> '/Users/henning/scratch/mjavadoc769/target/apidocs'
> -docencoding
> 'UTF-8'
> -Xdoclint:none
> -doctitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> -linkoffline
> 'https://docs.oracle.com/en/java/javase/11/docs/api'
> '/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
> -nohelp
> -use
> -version
> -windowtitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> {code}
> The javadoc plugin decides that the "javax.inject-1.jar" is added to the
> classpath even though it is an optional dependency of the main module.
> Contrary to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module
> path.
> The reason for this may be that the jakarta module contains a module-info
> (hidden in
[jira] [Comment Edited] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757065#comment-17757065
]
Henning Schmiedehausen edited comment on MJAVADOC-769 at 8/21/23 7:04 PM:
--
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc tool tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same was as module source FILENAME (iaw patched into the main
module).
was (Author: henning):
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc plugin tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same was as module source FILENAME (iaw patched into the main
module).
> javadoc plugin can not deal with optional dependencies when building java 9+
> javadocs
> -
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-99
[jira] [Comment Edited] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757065#comment-17757065
]
Henning Schmiedehausen edited comment on MJAVADOC-769 at 8/21/23 7:05 PM:
--
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc tool tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same way as module source FILENAME (iaw patched into the main
module).
was (Author: henning):
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc tool tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same was as module source FILENAME (iaw patched into the main
module).
> javadoc plugin can not deal with optional dependencies when building java 9+
> javadocs
> -
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-
[jira] [Updated] (MJAVADOC-769) javadoc plugin can not deal with transitive filename based modules
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-769:
Summary: javadoc plugin can not deal with transitive filename based modules
(was: javadoc plugin can not deal with optional dependencies when building
java 9+ javadocs)
> javadoc plugin can not deal with transitive filename based modules
> --
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
> -encoding
> 'UTF-8'
> -public
> -quiet
> --release
> 11
> -bottom
> 'Copyright © 2023. All rights reserved.'
> -charset
> 'UTF-8'
> -d
> '/Users/henning/scratch/mjavadoc769/target/apidocs'
> -docencoding
> 'UTF-8'
> -Xdoclint:none
> -doctitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> -linkoffline
> 'https://docs.oracle.com/en/java/javase/11/docs/api'
> '/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
> -nohelp
> -use
> -version
> -windowtitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> {code}
> The javadoc plugin decides that the "javax.inject-1.jar" is added to the
> classpath even though it is an optional dependency of the main module.
> Contrary to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module
> path.
> The reason for this may be that the jakarta module contains a module-info
> (hidden in META-INF/versions/9/) while the javax.inject jar does not.
> However, the checker-qual
> (org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar) dependency
> is put on the module path even though it does not contain a module-info file.
> However, it contains an {{Automatic-Module-Name}} entry in META-INF/MANIFEST.
> It seems that the javadoc plugin treats automatic dependencies with entry in
> the manifest different from automatic dependencies determined by filename.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-770) Allow building javadoc "the old fashioned way" after Java 8
Henning Schmiedehausen created MJAVADOC-770:
---
Summary: Allow building javadoc "the old fashioned way" after Java
8
Key: MJAVADOC-770
URL: https://issues.apache.org/jira/browse/MJAVADOC-770
Project: Maven Javadoc Plugin
Issue Type: Improvement
Components: javadoc
Affects Versions: 3.5.0
Reporter: Henning Schmiedehausen
The current javadoc plugin switches the way it executes the javadoc command
when the release / source version is 9 or better. Specifically, it starts using
the module path and tries to build docs using modules.
Up until Java 8, it simply creates a class path and executed the javadoc
command, creating a non-module aware set of documentation.
There are a lot of projects (mine included) that have moved past Java 8 but are
not ready to go full modularization. Those projects usually ship with
Automatic-Module-Name in the manifest.
The current JDK javadoc tooling does not work well with this type of project.
Especially the module-source-path setting only works with projects that have
module descriptors and javadoc chokes on patching a larger number of modules
("too many patched modules, use module-source-path"), making the aggregate goal
non viable for these projects.
One way to deal with this is to lock the release version for javadocs to "8".
However, once the source code moves past Java 8, the javadoc tool starts
throwing warnings (e.g. 'as of release 10, 'var' is a restricted type name and
cannot be used for type declarations or as the element type of an array').
The solution is actually simple: Allow a project to specify "the old way" of
creating javadocs using a classpath. I have verified this by building javadocs
using the "8" release version in debug mode, then manually changing the release
settings in the options file to "11" and running the javadoc.sh command. This
builds the javadocs as expected (java 11 syntax but non-module javadocs).
However, currently the switch between that style and "the new way" is attached
to release/source and can not be controlled independently.
I propose adding a new switch to the javadoc plugin (e.g. , as this
is called "legacy mode" in JEP 261) with a default to "false". Setting this
switch overrides the selection per release/source.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MJAVADOC-770) Allow building javadoc "the old fashioned way" after Java 8
[
https://issues.apache.org/jira/browse/MJAVADOC-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen reassigned MJAVADOC-770:
---
Assignee: Henning Schmiedehausen
> Allow building javadoc "the old fashioned way" after Java 8
> ---
>
> Key: MJAVADOC-770
> URL: https://issues.apache.org/jira/browse/MJAVADOC-770
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
>
> The current javadoc plugin switches the way it executes the javadoc command
> when the release / source version is 9 or better. Specifically, it starts
> using the module path and tries to build docs using modules.
> Up until Java 8, it simply creates a class path and executed the javadoc
> command, creating a non-module aware set of documentation.
> There are a lot of projects (mine included) that have moved past Java 8 but
> are not ready to go full modularization. Those projects usually ship with
> Automatic-Module-Name in the manifest.
> The current JDK javadoc tooling does not work well with this type of project.
> Especially the module-source-path setting only works with projects that have
> module descriptors and javadoc chokes on patching a larger number of modules
> ("too many patched modules, use module-source-path"), making the aggregate
> goal non viable for these projects.
> One way to deal with this is to lock the release version for javadocs to "8".
> However, once the source code moves past Java 8, the javadoc tool starts
> throwing warnings (e.g. 'as of release 10, 'var' is a restricted type name
> and cannot be used for type declarations or as the element type of an
> array').
> The solution is actually simple: Allow a project to specify "the old way" of
> creating javadocs using a classpath. I have verified this by building
> javadocs using the "8" release version in debug mode, then manually changing
> the release settings in the options file to "11" and running the javadoc.sh
> command. This builds the javadocs as expected (java 11 syntax but non-module
> javadocs).
> However, currently the switch between that style and "the new way" is
> attached to release/source and can not be controlled independently.
> I propose adding a new switch to the javadoc plugin (e.g. , as
> this is called "legacy mode" in JEP 261) with a default to "false". Setting
> this switch overrides the selection per release/source.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SUREFIRE-2190) optional dependencies and JPMS modules confuse surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved SUREFIRE-2190.
--
Fix Version/s: 3.x-candidate
Resolution: Fixed
> optional dependencies and JPMS modules confuse surefire
> ---
>
> Key: SUREFIRE-2190
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2190
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.1.2
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.x-candidate, 3.2.0
>
>
> The surefire plugin, when executing tests for JPMS code, patches the test
> code "into" the module under test (using {{{}--patch-module{}}}). This work
> for compile+runtime dependencies (`requires`) but not for compile
> required/runtime optional dependencies ({{{}requires static{}}}).
> The plugin only adds the module under test using {{--add-modules
> module.under.test.id}} to the JVM that is executing the test classes. As
> {{requires static}} dependencies are not loaded transitively, any dependency
> that is optional for the main artifact but required for test code is not
> found.
> clone and build the test repo: [https://github.com/hgschmie/msurefire2190]
> This repo contains three artifacts with identical code:
> thing1 builds a main artifact without JPMS
> thing2 builds a main artifact with a strong ({{{}requires{}}}) dependency on
> jakarta.annotation.
> thing3 builds a main artifact with a compile-only ({{requires static}})
> dependency on jakarta.annotation.
> The code and its test classes are otherwise identical.
> Running {{mvn -DskipTests}} clean install builds all three modules and the
> test code.
> Running {{mvn surefire:test}} passes the tests in the first two modules but
> fails in the third.
> Explanation:
> The surefire plugin, when it executes tests using JPMS adds all referenced
> modules to the module path (in this case the module under test itself and the
> jakarta.annotations-api jar). It then adds the main module using
> {{--add-modules}} and patches this module with the test classes (using
> {{{}-patch-module{}}}, so that the test classes execute as part of the module.
> In case of a compile+runtime ({{requires}}) relationship, the JVM will find
> the required JPMS module on the module path and add it as accessible. This is
> why the "thing2" tests pass.
> In case of a compile only/runtime optional ({{requires static}})
> relationship, the JVM will not add the module transitively as it is
> considered a compilation-only dependency. For the code under test to be able
> to access the classes from jakarta.annotation, they must be declared as a
> module. However, the test code only adds the module under test with
> {{--add-modules}}. So the test classes do not find any classes from the
> jakarta.annotation module and the test fails.
> The fix is simple: Instead of just adding the module under test using
> {{--add-modules}}, the surefire plugin should use {{-add-modules
> ALL-MODULE-PATH}}.
> Which is correct, because the code is not looking for compile time only
> dependencies but actual runtime dependencies where the code under execution
> may also need to access optional runtime dependencies (see
> [https://nipafx.dev/java-modules-optional-dependencies/] for a slightly
> longer explanation).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MJAVADOC-767) javadoc creates invalid --patch-module statements
[
https://issues.apache.org/jira/browse/MJAVADOC-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen reassigned MJAVADOC-767:
---
Assignee: Henning Schmiedehausen
> javadoc creates invalid --patch-module statements
> -
>
> Key: MJAVADOC-767
> URL: https://issues.apache.org/jira/browse/MJAVADOC-767
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
>
> Jdbi is a mixed Java/Kotlin multi-module project. We aggregate a final jar
> that contains all the javadocs for all modules in a doc step. This works ok
> for non-JPMS (Java 8 target).
> When introducing JPMS into our project, the javadoc plugin starts adding
> --patch-module options like this:
> {{--patch-module
> org.jdbi.v3.caffeine='/Users/henning/code/jdbi/cache/caffeine-cache/src/main/java:/Users/henning/code/jdbi/cache/caffeine-cache/target/generated-sources/annotations'}}
> However, in our configuration, we exclude the kotlin specific modules:
> {code:xml}
>
> maven-javadoc-plugin
>
>
> javadoc-jar
>
> jar
>
> package
>
> true
> false
>
>
> org.jdbi:*
>
>
>
> org.jdbi:jdbi3-kotlin
>
> org.jdbi:jdbi3-kotlin-sqlobject
>
>
> jdbi3-kotlin,jdbi3-kotlin-sqlobject
> Jdbi3 ${project.version} API
> Jdbi3 ${project.version} API
>
>
>
>
> {code}
> which results in the maven-javadoc-plugin creating command line options like
> this:
> {{--patch-module org.jdbi.v3.kotlin=}}
> which in turn crash the javadoc command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-767) javadoc creates invalid --patch-module statements
[
https://issues.apache.org/jira/browse/MJAVADOC-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved MJAVADOC-767.
-
Fix Version/s: 4.0.0
Resolution: Fixed
> javadoc creates invalid --patch-module statements
> -
>
> Key: MJAVADOC-767
> URL: https://issues.apache.org/jira/browse/MJAVADOC-767
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 4.0.0
>
>
> Jdbi is a mixed Java/Kotlin multi-module project. We aggregate a final jar
> that contains all the javadocs for all modules in a doc step. This works ok
> for non-JPMS (Java 8 target).
> When introducing JPMS into our project, the javadoc plugin starts adding
> --patch-module options like this:
> {{--patch-module
> org.jdbi.v3.caffeine='/Users/henning/code/jdbi/cache/caffeine-cache/src/main/java:/Users/henning/code/jdbi/cache/caffeine-cache/target/generated-sources/annotations'}}
> However, in our configuration, we exclude the kotlin specific modules:
> {code:xml}
>
> maven-javadoc-plugin
>
>
> javadoc-jar
>
> jar
>
> package
>
> true
> false
>
>
> org.jdbi:*
>
>
>
> org.jdbi:jdbi3-kotlin
>
> org.jdbi:jdbi3-kotlin-sqlobject
>
>
> jdbi3-kotlin,jdbi3-kotlin-sqlobject
> Jdbi3 ${project.version} API
> Jdbi3 ${project.version} API
>
>
>
>
> {code}
> which results in the maven-javadoc-plugin creating command line options like
> this:
> {{--patch-module org.jdbi.v3.kotlin=}}
> which in turn crash the javadoc command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-770) Allow building javadoc "the old fashioned way" after Java 8
[
https://issues.apache.org/jira/browse/MJAVADOC-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved MJAVADOC-770.
-
Fix Version/s: 3.5.1
Resolution: Fixed
merged PR
> Allow building javadoc "the old fashioned way" after Java 8
> ---
>
> Key: MJAVADOC-770
> URL: https://issues.apache.org/jira/browse/MJAVADOC-770
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.5.1
>
>
> The current javadoc plugin switches the way it executes the javadoc command
> when the release / source version is 9 or better. Specifically, it starts
> using the module path and tries to build docs using modules.
> Up until Java 8, it simply creates a class path and executed the javadoc
> command, creating a non-module aware set of documentation.
> There are a lot of projects (mine included) that have moved past Java 8 but
> are not ready to go full modularization. Those projects usually ship with
> Automatic-Module-Name in the manifest.
> The current JDK javadoc tooling does not work well with this type of project.
> Especially the module-source-path setting only works with projects that have
> module descriptors and javadoc chokes on patching a larger number of modules
> ("too many patched modules, use module-source-path"), making the aggregate
> goal non viable for these projects.
> One way to deal with this is to lock the release version for javadocs to "8".
> However, once the source code moves past Java 8, the javadoc tool starts
> throwing warnings (e.g. 'as of release 10, 'var' is a restricted type name
> and cannot be used for type declarations or as the element type of an
> array').
> The solution is actually simple: Allow a project to specify "the old way" of
> creating javadocs using a classpath. I have verified this by building
> javadocs using the "8" release version in debug mode, then manually changing
> the release settings in the options file to "11" and running the javadoc.sh
> command. This builds the javadocs as expected (java 11 syntax but non-module
> javadocs).
> However, currently the switch between that style and "the new way" is
> attached to release/source and can not be controlled independently.
> I propose adding a new switch to the javadoc plugin (e.g. , as
> this is called "legacy mode" in JEP 261) with a default to "false". Setting
> this switch overrides the selection per release/source.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-701) javadoc site is broken for projects that contain modules
[
https://issues.apache.org/jira/browse/MJAVADOC-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved MJAVADOC-701.
-
Fix Version/s: 3.5.1
Assignee: Henning Schmiedehausen
Resolution: Fixed
> javadoc site is broken for projects that contain modules
>
>
> Key: MJAVADOC-701
> URL: https://issues.apache.org/jira/browse/MJAVADOC-701
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
> Environment: Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.5.1
>
>
> How to reproduce:
>
> {{% git clone [https://github.com/hgschmie/pg-embedded.git]}}
> {{% cd pg-embedded}}
> {{% git checkout -b 4.0-branch pg-embedded-4.0}}
> {{% ./mvnw clean site}}
> {{% ls target/site/apidocs}}
> {{allclasses-index.html jquery-ui.overrides.css script-dir}}
> {{allpackages-index.html legal script.js}}
> {{constant-values.html member-search-index.js search.js}}
> {{de module-search-index.js src-html}}
> {{deprecated-list.html overview-summary.html stylesheet.css}}
> {{element-list overview-tree.html tag-search-index.js}}
> {{index-all.html package-search-index.js type-search-index.js}}
> {{index.html resources}}
> {{% ./mvnw clean install site}}
> {{% ls target/site/apidocs}}
> {{allclasses-index.html overview-tree.html}}
> {{allpackages-index.html package-search-index.js}}
> {{constant-values.html resources}}
> {{{color:#ff}*de.softwareforge.testing.postgres*{color} script-dir}}
> {{deprecated-list.html script.js}}
> {{element-list search.js}}
> {{index-all.html src}}
> {{index.html src-html}}
> {{jquery-ui.overrides.css stylesheet.css}}
> {{legal tag-search-index.js}}
> {{member-search-index.js type-search-index.js}}
> {{module-search-index.js}}
> ==> If the build only creates the site (run aggregate-no-fork, javadoc,
> javadoc-no-fork), it will not contain the module subfolder
> (de.softwareforge.testing.postgres)
> ==> if the build also runs the "javadoc:jar" goal, the site will contain the
> module subfolder
>
> I have looked through the debug output and the options to the maven javadoc
> plugin execution but nothing stands out. Just that one builds the module
> javadoc correctly and the other does not.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-701) javadoc site is broken for projects that contain modules
[
https://issues.apache.org/jira/browse/MJAVADOC-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763200#comment-17763200
]
Henning Schmiedehausen commented on MJAVADOC-701:
-
This is caused by maven looking at the unbuilt project and deciding that it is
a pre-java 9 project (no module-info, no artifact) and thus builds a "legacy"
maven site. When the project is built, it inspects the jar, sees the
automatic-module-name entry and decides that this is a java 9+ project and
builds a module enabled maven site.
This is fixed by MJAVADOC-770 and turning on "legacy" mode.
> javadoc site is broken for projects that contain modules
>
>
> Key: MJAVADOC-701
> URL: https://issues.apache.org/jira/browse/MJAVADOC-701
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
> Environment: Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> How to reproduce:
>
> {{% git clone [https://github.com/hgschmie/pg-embedded.git]}}
> {{% cd pg-embedded}}
> {{% git checkout -b 4.0-branch pg-embedded-4.0}}
> {{% ./mvnw clean site}}
> {{% ls target/site/apidocs}}
> {{allclasses-index.html jquery-ui.overrides.css script-dir}}
> {{allpackages-index.html legal script.js}}
> {{constant-values.html member-search-index.js search.js}}
> {{de module-search-index.js src-html}}
> {{deprecated-list.html overview-summary.html stylesheet.css}}
> {{element-list overview-tree.html tag-search-index.js}}
> {{index-all.html package-search-index.js type-search-index.js}}
> {{index.html resources}}
> {{% ./mvnw clean install site}}
> {{% ls target/site/apidocs}}
> {{allclasses-index.html overview-tree.html}}
> {{allpackages-index.html package-search-index.js}}
> {{constant-values.html resources}}
> {{{color:#ff}*de.softwareforge.testing.postgres*{color} script-dir}}
> {{deprecated-list.html script.js}}
> {{element-list search.js}}
> {{index-all.html src}}
> {{index.html src-html}}
> {{jquery-ui.overrides.css stylesheet.css}}
> {{legal tag-search-index.js}}
> {{member-search-index.js type-search-index.js}}
> {{module-search-index.js}}
> ==> If the build only creates the site (run aggregate-no-fork, javadoc,
> javadoc-no-fork), it will not contain the module subfolder
> (de.softwareforge.testing.postgres)
> ==> if the build also runs the "javadoc:jar" goal, the site will contain the
> module subfolder
>
> I have looked through the debug output and the options to the maven javadoc
> plugin execution but nothing stands out. Just that one builds the module
> javadoc correctly and the other does not.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-764) javadoc:aggregate fails after Java 11 upgrade
[
https://issues.apache.org/jira/browse/MJAVADOC-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763207#comment-17763207
]
Henning Schmiedehausen commented on MJAVADOC-764:
-
You are most likely using the "automatic module name" style of JPMS modules.
The aggregation target only works with maven modules that build defined JPMS
modules (that have a module-info descriptor). This is a limitation of the JVM
toolchain.
> javadoc:aggregate fails after Java 11 upgrade
> --
>
> Key: MJAVADOC-764
> URL: https://issues.apache.org/jira/browse/MJAVADOC-764
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Sirisha Pratha
>Priority: Blocker
>
> We have a multi-module project that is failing for javadoc:aggregate goal
> after upgrading to Java 11 for maven-javadoc-plugin versions 3.4.1 and 3.5.0.
> It worked fine without any issues for Java 1.8.
> This is our maven-javadoc plugin configuration for Java 8 -
> {color:#00875a}*SUCCESS*{color}
>
> {noformat}
> 8
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/javase/8/docs/api/
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
>
> {noformat}
> This is our maven-javadoc plugin configuration for Java 11 - (the only
> difference is values in source and links tags) -
> *{color:#ff}FAILS{color}* {color:#ff}(See error below){color}
>
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/en/java/javase/11/docs/api
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
> {noformat}
>
> _javadoc:aggregate_ fails with the following error on our GitHub workflow
> (nothing changed in the way we run this job - we have always used Java 17 to
> run this)
>
> {noformat}
> Error: 6:236 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:aggregate (default-cli)
> on project eclipse-collections-parent: An error has occurred in Javadoc
> report generation:
> 515Error: 6:236 [ERROR] Exit code: 2 - Loading source files for package
> org.eclipse.collections.codegenerator.model...
> 516Error: 02:14:46:236 [ERROR] error: No source files for package
> org.eclipse.collections.codegenerator.model
> 517Error: 02:14:46:237 [ERROR] 1 error
> 518Error: 6:237 [ERROR]
> 519Error: 6:238 [ERROR] Command line was:
> /opt/hostedtoolcache/Java_Zulu_jdk/17.0.7-7/x64/bin/javadoc @options @packages
> 520Error: 6:238 [ERROR]
> 521Error: 6:238 [ERROR] Refer to the generated Javadoc files in
> '/home/runner/work/eclipse-collections/eclipse-collections/target/site/apidocs/12.0.0-SNAPSHOT'
> dir.
> 522Error: 6:239 [ERROR]
> 523Error: 6:240 [ERROR] -> [Help 1]{noformat}
>
>
> Solutions we tried -
> # Configuring sourcePath (see below) - in this case, *no Javadoc was
> created* in target/site/apidocs.
> {noformat}
> ${project.build.sourceDirectory}{noformat}
> # Tried both plugin versions 3.4.1 and 3.5.0 - *fails* w
[jira] [Assigned] (MJAVADOC-753) javadoc plugin does not find sources in auto-module when creating docs
[
https://issues.apache.org/jira/browse/MJAVADOC-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen reassigned MJAVADOC-753:
---
Assignee: Henning Schmiedehausen
> javadoc plugin does not find sources in auto-module when creating docs
> --
>
> Key: MJAVADOC-753
> URL: https://issues.apache.org/jira/browse/MJAVADOC-753
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Blocker
>
> clone this repo: [https://github.com/hgschmie/javadoc-bug]
> run "mvn clean install"
> expected outcome: builds a project, generates a javadoc jar
> observed outcome:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (basepom.default) on
> project javadoc-bug: MavenReportException: Error while generating Javadoc:}}
> {{[ERROR] Exit code: 1}}
> {{[ERROR]
> /Users/henning/oss/bugs/javadoc/src/main/java/maven/bugs/internal/InternalImportBindingBuilder.java:7:
> error: cannot access Provider}}
> {{[ERROR] static final class InternalBindingProvider implements
> Provider {}}
> {{[ERROR] ^}}
> {{[ERROR] class file for javax.inject.Provider not found}}
> {{[ERROR] 1 error}}
> {{[ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages}}
> Setting the release to "8" works (but loses the module information)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
[
https://issues.apache.org/jira/browse/MJAVADOC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-747:
Labels: jpms (was: )
> jar goal fails with automatic module (Regression from 3.2.0)
> -
>
> Key: MJAVADOC-747
> URL: https://issues.apache.org/jira/browse/MJAVADOC-747
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0
>Reporter: Geoffrey De Smet
>Priority: Blocker
> Labels: jpms
>
> In optaplanner, we provide automatic module names for all our modules.
> But some modules have a dependency with classes in the no-name package.
> That was not a problem for the maven-javadoc-plugin, except since
> maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
> This happens with dependencies on quarkus and on rewrite.
> For example, for optaplanner-migrator that depends on rewrite-maven and
> rewrite-gradle:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
> reproducer:
> Execution default of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
> Unable to derive module descriptor for
> /.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
> PluginSpec.class found in top-level directory (unnamed package not allowed in
> module) -> [Help 1]{code}
> Isolated reproducer:
> [https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-753) javadoc plugin does not find sources in auto-module when creating docs
[
https://issues.apache.org/jira/browse/MJAVADOC-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved MJAVADOC-753.
-
Resolution: Fixed
> javadoc plugin does not find sources in auto-module when creating docs
> --
>
> Key: MJAVADOC-753
> URL: https://issues.apache.org/jira/browse/MJAVADOC-753
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Blocker
>
> clone this repo: [https://github.com/hgschmie/javadoc-bug]
> run "mvn clean install"
> expected outcome: builds a project, generates a javadoc jar
> observed outcome:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (basepom.default) on
> project javadoc-bug: MavenReportException: Error while generating Javadoc:}}
> {{[ERROR] Exit code: 1}}
> {{[ERROR]
> /Users/henning/oss/bugs/javadoc/src/main/java/maven/bugs/internal/InternalImportBindingBuilder.java:7:
> error: cannot access Provider}}
> {{[ERROR] static final class InternalBindingProvider implements
> Provider {}}
> {{[ERROR] ^}}
> {{[ERROR] class file for javax.inject.Provider not found}}
> {{[ERROR] 1 error}}
> {{[ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages}}
> Setting the release to "8" works (but loses the module information)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-764) javadoc:aggregate fails after Java 11 upgrade
[
https://issues.apache.org/jira/browse/MJAVADOC-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-764:
Labels: jpms (was: )
> javadoc:aggregate fails after Java 11 upgrade
> --
>
> Key: MJAVADOC-764
> URL: https://issues.apache.org/jira/browse/MJAVADOC-764
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Sirisha Pratha
>Priority: Blocker
> Labels: jpms
>
> We have a multi-module project that is failing for javadoc:aggregate goal
> after upgrading to Java 11 for maven-javadoc-plugin versions 3.4.1 and 3.5.0.
> It worked fine without any issues for Java 1.8.
> This is our maven-javadoc plugin configuration for Java 8 -
> {color:#00875a}*SUCCESS*{color}
>
> {noformat}
> 8
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/javase/8/docs/api/
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
>
> {noformat}
> This is our maven-javadoc plugin configuration for Java 11 - (the only
> difference is values in source and links tags) -
> *{color:#ff}FAILS{color}* {color:#ff}(See error below){color}
>
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/en/java/javase/11/docs/api
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
> {noformat}
>
> _javadoc:aggregate_ fails with the following error on our GitHub workflow
> (nothing changed in the way we run this job - we have always used Java 17 to
> run this)
>
> {noformat}
> Error: 6:236 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:aggregate (default-cli)
> on project eclipse-collections-parent: An error has occurred in Javadoc
> report generation:
> 515Error: 6:236 [ERROR] Exit code: 2 - Loading source files for package
> org.eclipse.collections.codegenerator.model...
> 516Error: 02:14:46:236 [ERROR] error: No source files for package
> org.eclipse.collections.codegenerator.model
> 517Error: 02:14:46:237 [ERROR] 1 error
> 518Error: 6:237 [ERROR]
> 519Error: 6:238 [ERROR] Command line was:
> /opt/hostedtoolcache/Java_Zulu_jdk/17.0.7-7/x64/bin/javadoc @options @packages
> 520Error: 6:238 [ERROR]
> 521Error: 6:238 [ERROR] Refer to the generated Javadoc files in
> '/home/runner/work/eclipse-collections/eclipse-collections/target/site/apidocs/12.0.0-SNAPSHOT'
> dir.
> 522Error: 6:239 [ERROR]
> 523Error: 6:240 [ERROR] -> [Help 1]{noformat}
>
>
> Solutions we tried -
> # Configuring sourcePath (see below) - in this case, *no Javadoc was
> created* in target/site/apidocs.
> {noformat}
> ${project.build.sourceDirectory}{noformat}
> # Tried both plugin versions 3.4.1 and 3.5.0 - *fails* with both versions.
> # Tried to add source = 1.8 but maven.compiler.source = 11, which seems to
> be the only combination that {*}works{*}. Like so -
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> 1.8
> Eclipse Collectio
[jira] [Updated] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used
[ https://issues.apache.org/jira/browse/MJAVADOC-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MJAVADOC-707: Labels: jpms (was: ) > Plugin won't work if Automatic-Module-Name is used > -- > > Key: MJAVADOC-707 > URL: https://issues.apache.org/jira/browse/MJAVADOC-707 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.3.1, 3.3.2, 3.4.0 >Reporter: Christopher Tubbs >Priority: Critical > Labels: jpms > > Using Automatic-Module-Name in a manifest (an intermediate step to help > transition to using modules) prevents this plugin from adding the necessary > dependencies to the class path, so it can build javadocs. > maven-compiler-plugin seems to work fine, as does surefire and all the others > when Automatic-Module-Name entries appear in a project's jar manifests. > However, this plugin, as of 3.3.1, still does not work correctly with these. > Instead of using the traditional class path, this plugin seems to force > treating the project as a module, even though it does not have any > module-info.java files, and most of its dependencies have not transitioned to > using modules. > Here's a pull request that demonstrates adding the Automatic-Module-Name to > the manifest for a multi-module (Maven module) project, that fails on the > javadoc plugin: > https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and > javadoc:jar are known to fail. I did not test with any other mojos. > Not supporting this feature holds all projects back from being able to > transition to modules over time. > http://branchandbound.net/blog/java/2017/12/automatic-module-name/ > https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-769) javadoc plugin can not deal with transitive filename based modules
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved MJAVADOC-769.
-
Fix Version/s: 3.5.1
Assignee: Henning Schmiedehausen
Resolution: Fixed
> javadoc plugin can not deal with transitive filename based modules
> --
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.5.1
>
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
> -encoding
> 'UTF-8'
> -public
> -quiet
> --release
> 11
> -bottom
> 'Copyright © 2023. All rights reserved.'
> -charset
> 'UTF-8'
> -d
> '/Users/henning/scratch/mjavadoc769/target/apidocs'
> -docencoding
> 'UTF-8'
> -Xdoclint:none
> -doctitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> -linkoffline
> 'https://docs.oracle.com/en/java/javase/11/docs/api'
> '/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
> -nohelp
> -use
> -version
> -windowtitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> {code}
> The javadoc plugin decides that the "javax.inject-1.jar" is added to the
> classpath even though it is an optional dependency of the main module.
> Contrary to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module
> path.
> The reason for this may be that the jakarta module contains a module-info
> (hidden in META-INF/versions/9/) while the javax.inject jar does not.
> However, the checker-qual
> (org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar) dependency
> is put on the module path even though it does not contain a module-info file.
> However, it contains an {{Automatic-Module-Name}} entry in META-INF/MANIFEST.
> It seems that the javadoc plugin treats automatic dependencies with entry in
> the manifest different from automatic dependencies determined by filename.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-768) javadoc has a hard time with JPMS and provided or optional module dependencies.
[
https://issues.apache.org/jira/browse/MJAVADOC-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-768:
Labels: jpms (was: )
> javadoc has a hard time with JPMS and provided or optional module
> dependencies.
> ---
>
> Key: MJAVADOC-768
> URL: https://issues.apache.org/jira/browse/MJAVADOC-768
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
> Labels: jpms
>
> Check out this project: [https://github.com/hgschmie/mjavadoc768/]
> run {{mvn clean install}} in the root. This results in this error:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:aggregate-jar
> (javadoc-jar) on project doc: MavenReportException: Error while generating
> Javadoc:
> [ERROR] Exit code: 1
> [ERROR] /Users/henning/scratch/jdbug/thing2/src/main/java/module-info.java:4:
> error: module not found: jakarta.annotation
> [ERROR] requires static jakarta.annotation;
> [ERROR] ^
> [ERROR] /Users/henning/scratch/jdbug/thing1/src/main/java/module-info.java:4:
> error: module not found: jakarta.annotation
> [ERROR] requires static jakarta.annotation;
> [ERROR] ^
> [ERROR] 2 errors
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/henning/scratch/jdbug/doc/target/apidocs' dir.
> {code}
> The problem is that both maven modules (thing1 and thing2) declare a compile
> time dependency on "jakarta-annotation" using either maven {{provided}} scope
> or maven {{optional}}. This is reflected in the JPMS module descriptor by
> using `required static jakarta.annotation;`.
> But the javadoc tool, when it wants to generate the aggregation jar,
> generates an options file that does not contain the jakarta-annotation jar on
> the module path (which is needed for javadoc to succeed), so the tool reports
> the error above. The javadoc tool needs to add all provided and optional
> dependencies to the module path for the aggregated jar.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-760) Cleanup dependency declarations as best possible
[ https://issues.apache.org/jira/browse/MJAVADOC-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved MJAVADOC-760. - Fix Version/s: 3.5.1 Resolution: Fixed PRs have been merged. > Cleanup dependency declarations as best possible > > > Key: MJAVADOC-760 > URL: https://issues.apache.org/jira/browse/MJAVADOC-760 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.5.1 > > > [WARNING] Used undeclared dependencies found: > [WARNING]org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.5:compile > [WARNING]org.slf4j:slf4j-api:jar:1.7.36:compile > [WARNING]org.apache.maven.shared:maven-shared-utils:jar:3.3.4:compile > [WARNING]org.eclipse.aether:aether-impl:jar:1.0.0.v20140518:provided > [WARNING]javax.servlet:javax.servlet-api:jar:3.1.0:test > [WARNING]org.hamcrest:hamcrest-core:jar:1.3:test > [WARNING]org.eclipse.aether:aether-util:jar:1.0.0.v20140518:compile > [WARNING]org.codehaus.plexus:plexus-io:jar:3.4.0:compile > [WARNING]org.codehaus.plexus:plexus-archiver:jar:4.4.0:compile > [WARNING]org.eclipse.aether:aether-api:jar:1.0.0.v20140518:compile > [WARNING]org.eclipse.jetty:jetty-util:jar:9.4.50.v20221201:test > [WARNING] Unused declared dependencies found: > [WARNING]org.eclipse.jetty:jetty-client:jar:9.4.50.v20221201:test > [WARNING] > org.eclipse.aether:aether-connector-basic:jar:1.0.0.v20140518:test > [WARNING] > org.eclipse.aether:aether-transport-wagon:jar:1.0.0.v20140518:test > [WARNING]org.apache.maven.wagon:wagon-http:jar:shaded:2.4:test > [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test > [WARNING] Non-test scoped test only dependencies found: > [WARNING]org.slf4j:slf4j-api:jar:1.7.36:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-698) javadoc:javadoc fails for non-JPMS mojo
[
https://issues.apache.org/jira/browse/MJAVADOC-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-698:
Labels: jpms (was: )
> javadoc:javadoc fails for non-JPMS mojo
> ---
>
> Key: MJAVADOC-698
> URL: https://issues.apache.org/jira/browse/MJAVADOC-698
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
>Reporter: Gili
>Priority: Major
> Labels: jpms
>
> I upgraded maven-javadoc-plugin from version 3.2.0 to 3.3.1. At the same
> time, I upgraded from JDK 11 to 17. All of a sudden I am getting the
> following build failure I was not getting before:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project maven_plugin: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\AbstractGeneratorMojo.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\GenerateApiMojo.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\OptimizeExceptionsMojo.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\package-info.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\src\main\java\com\github\cowwoc\requirements\maven\UnpackMojo.java...
> [ERROR] Loading source file
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java...
> [ERROR] Loading source files for package
> com.github.cowwoc.requirements.maven...
> [ERROR] Constructing Javadoc information...
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:8:
> error: package org.w3c.dom is not visible
> [ERROR] import org.w3c.dom.Document;
> [ERROR] ^
> [ERROR] (package org.w3c.dom is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:9:
> error: package org.w3c.dom is not visible
> [ERROR] import org.w3c.dom.Element;
> [ERROR] ^
> [ERROR] (package org.w3c.dom is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:10:
> error: package org.w3c.dom is not visible
> [ERROR] import org.w3c.dom.Node;
> [ERROR] ^
> [ERROR] (package org.w3c.dom is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:11:
> error: package org.w3c.dom is not visible
> [ERROR] import org.w3c.dom.NodeList;
> [ERROR] ^
> [ERROR] (package org.w3c.dom is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:12:
> error: package org.xml.sax is not visible
> [ERROR] import org.xml.sax.SAXException;
> [ERROR] ^
> [ERROR] (package org.xml.sax is declared in module java.xml, but module
> com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:14:
> error: package javax.xml.parsers is not visible
> [ERROR] import javax.xml.parsers.DocumentBuilder;
> [ERROR] ^
> [ERROR] (package javax.xml.parsers is declared in module java.xml, but
> module com.github.cowwoc.requirements.maven_plugin does not read it)
> [ERROR]
> C:\Users\Gili\Documents\requirements.java\maven_plugin\target\generated-sources\plugin\com\github\cowwoc\requirements\maven\HelpMojo.java:15:
> error: package javax.xml.parsers is not visible
> [ERROR] import javax.xml.parsers.DocumentBuilderFactory;
> [ERROR] ^
> [ERROR] (package javax.xml.parse
[jira] [Updated] (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:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-682:
Labels: jpms (was: )
> 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
> Environment: Debian Linux versions 10.10 through 11.4
> OpenJDK 64-bit versions 11.0.11 through 11.0.16
> Maven versions 3.8.1 through 3.8.6
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.4.1, 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] [Updated] (MJAVADOC-734) javadoc drops copying doc-files when module-info.java file present
[ https://issues.apache.org/jira/browse/MJAVADOC-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MJAVADOC-734: Labels: jpms (was: ) > javadoc drops copying doc-files when module-info.java file present > -- > > Key: MJAVADOC-734 > URL: https://issues.apache.org/jira/browse/MJAVADOC-734 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Affects Versions: 3.4.1 >Reporter: Pieter van den Hombergh >Priority: Major > Labels: jpms > > the javadoc no longer copies the files found under doc-files to the > appropriate spot in the apidoc tree. > > The files should be present at the relative location near the html files > generated from the java files. e.g. in the module com.example the file > src/main/java/hello/doc-files/Hi.png should land under > target/apidocs/com.example/hello/doc-files/Hi.png > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-733) Alternative doclet page points to an SEO spammy page
[ https://issues.apache.org/jira/browse/MJAVADOC-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved MJAVADOC-733. - Resolution: Fixed > Alternative doclet page points to an SEO spammy page > > > Key: MJAVADOC-733 > URL: https://issues.apache.org/jira/browse/MJAVADOC-733 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Major > > On the page > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html > the site http://www.umlgraph.org/ is no longer valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-736) Plugin fails to detect module descriptor if mvn clean run during initialize phase
[
https://issues.apache.org/jira/browse/MJAVADOC-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-736:
Labels: jpms (was: )
> Plugin fails to detect module descriptor if mvn clean run during initialize
> phase
> -
>
> Key: MJAVADOC-736
> URL: https://issues.apache.org/jira/browse/MJAVADOC-736
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
> Environment: macOS 12.6, JDK 19 (installed via homebrew), Apache
> Maven 3.8.6
>Reporter: Daniel Widdis
>Priority: Major
> Labels: jpms
>
> When the clean goal of maven-clean-plugin is invoked during the initialize
> phase, maven-javadoc-plugin fails to find the module descriptor. Analysis of
> the search logic reveals that if an output directory exists, but either a jar
> doesn't exist or the jar does not contain an Automatic-Module-Name, the mojo
> never reaches the code branch where a module descriptor is searched for.
> Steps to reproduce:
> # Create a simple project with a module-info.java file, but no automatic
> module name.
> # Invoke the `clean` goal of `maven-clean-plugin` during the initialize
> phase (either automatically in pom, or by running `mvn clean`)
> # Run `mvn javadoc:javadoc` or `mvn javadoc:jar`
> Expected result:
> {{[INFO] — maven-javadoc-plugin:3.4.1:javadoc (default-cli) @ foo ---}}
> {{[INFO] Configuration changed, re-generating javadoc.}}
> {{[INFO]
> }}
> {{[INFO] BUILD SUCCESS}}
> Actual result:
> {{[INFO] — maven-javadoc-plugin:3.4.1:javadoc (default-cli) @ foo ---}}
> {{[ERROR] Creating an aggregated report for both named and unnamed modules is
> not possible.}}
> {{[ERROR] Ensure that every module has a module descriptor or is a jar with a
> MANIFEST.MF containing an Automatic-Module-Name.}}
> {{[ERROR] Fix the following projects:}}
> {{[ERROR] - foo:foo}}
> Minimal reproducer project: [https://github.com/dbwiddis/foo]
> Probable source of the error:
> [https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L4999-L5096]
> In AbstractJavadocMojo beginning at line 4999, a list of unnamedProjects is
> created. It is added to on line 5070 when `result` shows a failure to find
> the module descriptor.
> There are two chances to set result, one at line 5014 (searching for
> automatic module name in the jar) and one at line 5037 (searching for module
> descriptor). However, these two options are in an if/else block conditioned
> on the presence of the artifact file (directory), so if that value is not
> null, the second check never occurs.
> Following the getClassesFile() logic (called from line 5008, executing line
> 1709) we see in line 1737 that if the output directory exists, that directory
> is returned and the code never reaches the null return at line 1741.
> Possible fix: replace the if/else conditional with an if conditional, and
> condition the second branch (currently "else") to be a second check on
> whether `result` is null.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-642) Setting maven.javadoc.isoffline seems to have no effect
[
https://issues.apache.org/jira/browse/MJAVADOC-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763229#comment-17763229
]
Henning Schmiedehausen commented on MJAVADOC-642:
-
The explanation above is wrong.
The "isOffline" setting is controlled by "${settings.offline}", which is part
of the maven internal settings. It can not be controlled by
{{-Dsettings.offline=true}} but by passing the {{-o}} parameter to maven.
Neither setting maven.javadoc.isOffline nor setting settings.offline on the
command line has any effect.
Currently, the only way to run the javadoc plugin in offline mode is to pass
the {{-o}} flag to maven itself. I will add a property setting in a PR and
then close this issue as fixed.
> Setting maven.javadoc.isoffline seems to have no effect
> ---
>
> Key: MJAVADOC-642
> URL: https://issues.apache.org/jira/browse/MJAVADOC-642
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.1
>Reporter: Thomas Cunningham
>Priority: Major
> Fix For: wontfix-candidate, waiting-for-feedback
>
>
> I'm trying to work around MJAVADOC-641 and the proxy issues that we are
> having, and I'd like to set isOffline to true. I tried to do this my
> setting -Dmaven.javadoc.isOffline=true in my maven invocation, and it doesn't
> seem to take effect. Setting isOffline to true within the
> allows my build to succeed.
> Am I using the wrong command line property for isOffline?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-702) javadoc site creation ignores configuration parameters
[
https://issues.apache.org/jira/browse/MJAVADOC-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved MJAVADOC-702.
-
Fix Version/s: 3.5.0
Resolution: Cannot Reproduce
No longer reproducible with 3.5.0
> javadoc site creation ignores configuration parameters
> --
>
> Key: MJAVADOC-702
> URL: https://issues.apache.org/jira/browse/MJAVADOC-702
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
> Environment: Apache Maven 3.8.4
> (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.5.0
>
>
> how to reproduce:
> {{% git clone https://github.com/hgschmie/pg-embedded.git}}
> {{% cd pg-embedded}}
> {{% ./mvnw clean install site}}
> Point a browser at the local target/apidocs folder. The generated javadocs do
> not have a HELP menu item on top and references to Guava, JUnit5 etc. have
> been resolved and are linked.
> Point a browser at target/site/apidocs. The javadocs here do have a HELP menu
> item and references to JUnit 5 etc. are fully qualified class names without
> links.
> The debug log shows that the javadoc-no-fork goal is run with a lot of
> configuration options, including multiple duplicates:
> {{[DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:test-javadoc-no-fork'
> with basic configurator -->}}
> {{[DEBUG] (f) release = 11}}
> {{[DEBUG] (f) source = 11}}
> {{[DEBUG] (f) encoding = UTF-8}}
> {{[DEBUG] (f) maxmemory = 1024m}}
> {{[DEBUG] (f) quiet = true}}
> {{[DEBUG] (f) doclint = none}}
> {{[DEBUG] (f) show = protected}}
> {{[DEBUG] (f) links = [https://junit.org/junit5/docs/5.8.1/api/,
> https://javadoc.io/doc/com.google.guava/guava/30.1.1-jre/,
> https://javadoc.io/doc/com.github.spotbugs/spotbugs-annotations/4.4.2]}}
> {{[DEBUG] (f) author = false}}
> {{[DEBUG] (f) detectJavaApiLink = true}}
> {{[DEBUG] (f) linksource = true}}
> {{[DEBUG] (f) nodeprecated = false}}
> {{[DEBUG] (f) nohelp = true}}
> {{[DEBUG] (f) skip = false}}
> {{[DEBUG] (f) failOnError = true}}
> {{[DEBUG] (f) release = 11}}
> {{[DEBUG] (f) source = 11}}
> {{[DEBUG] (f) encoding = UTF-8}}
> {{[DEBUG] (f) maxmemory = 1024m}}
> {{[DEBUG] (f) quiet = true}}
> {{[DEBUG] (f) doclint = none}}
> {{[DEBUG] (f) show = protected}}
> {{[DEBUG] (f) links = [https://junit.org/junit5/docs/5.8.1/api/,
> https://javadoc.io/doc/com.google.guava/guava/30.1.1-jre/,
> https://javadoc.io/doc/com.github.spotbugs/spotbugs-annotations/4.4.2]}}
> {{[DEBUG] (f) author = false}}
> {{[DEBUG] (f) detectJavaApiLink = true}}
> {{[DEBUG] (f) linksource = true}}
> {{[DEBUG] (f) nodeprecated = false}}
> {{[DEBUG] (f) nohelp = true}}
> {{[DEBUG] (f) applyJavadocSecurityFix = true}}
> {{[DEBUG] (f) author = true}}
> {{[DEBUG] (f) bootclasspathArtifacts = []}}
> {{[DEBUG] (f) bottom = Copyright ©
> \{inceptionYear\}–\{currentYear\} \{organizationName\}. All rights
> reserved.}}
> {{[DEBUG] (f) breakiterator = false}}
> {{[DEBUG] (f) debug = false}}
> {{[DEBUG] (s) destDir = testapidocs}}
> {{[DEBUG] (f) detectJavaApiLink = true}}
> {{[DEBUG] (f) detectLinks = false}}
> {{[DEBUG] (f) detectOfflineLinks = true}}
> {{[DEBUG] (f) docencoding = UTF-8}}
> {{[DEBUG] (f) docfilessubdirs = false}}
> {{[DEBUG] (f) docletArtifact = groupId = 'null' artifactId = 'null' version
> = 'null' classifier = 'null'}}
> {{[DEBUG] (f) docletArtifacts = []}}
> {{[DEBUG] (f) doctitle = pg-embedded 4.1-SNAPSHOT API}}
> {{[DEBUG] (f) encoding = UTF-8}}
> {{[DEBUG] (f) failOnError = true}}
> {{[DEBUG] (f) failOnWarnings = false}}
> {{[DEBUG] (f) includeDependencySources = false}}
> {{[DEBUG] (f) includeTransitiveDependencySources = false}}
> {{[DEBUG] (f) isOffline = false}}
> {{[DEBUG] (f) javaApiLinks = {}}}
> {{[DEBUG] (f) javadocDirectory =
> /Users/henning/code/pg-embedded/src/main/javadoc}}
> {{[DEBUG] (f) javadocOptionsDir =
> /Users/henning/code/pg-embedded/target/javadoc-bundle-options}}
> {{[DEBUG] (f) keywords = false}}
> {{[DEBUG] (f) links = []}}
> {{[DEBUG] (f) linksource = false}}
> {{[DEBUG] (f) localRepository = id: local url:
> file:///Users/henning/.m2/repository/layout: default snapshots: [enabled
> => true, update => always] releases: [enabled => true, update => always]
> blocked: false}}
> {{[DEBUG] (f) mojo =
> org.apac
[jira] [Resolved] (MJAVADOC-758) IOException --> NullPointerException in JavadocUtil.copyResource
[
https://issues.apache.org/jira/browse/MJAVADOC-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved MJAVADOC-758.
-
Fix Version/s: 3.5.1
Resolution: Fixed
> IOException --> NullPointerException in JavadocUtil.copyResource
>
>
> Key: MJAVADOC-758
> URL: https://issues.apache.org/jira/browse/MJAVADOC-758
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Minor
> Fix For: 3.5.1
>
>
> These are not IOExceptions. They are null pointers
> {{
> protected static void copyResource(URL url, File file) throws IOException
> {
> if (file == null) {
> throw new IOException("The file can't be null.");
> }
> if (url == null) {
> throw new IOException("The url could not be null.");
> }
> FileUtils.copyURLToFile(url, file);
> }}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-642) Setting maven.javadoc.isoffline seems to have no effect
[
https://issues.apache.org/jira/browse/MJAVADOC-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763268#comment-17763268
]
Henning Schmiedehausen commented on MJAVADOC-642:
-
as a side note, while {{}} works, it was never documented (it was
intended for internal use). The next release (3.6.0) will expose a
{{}} configuration setting that serves the same purpose. You may need
to fix your build.
> Setting maven.javadoc.isoffline seems to have no effect
> ---
>
> Key: MJAVADOC-642
> URL: https://issues.apache.org/jira/browse/MJAVADOC-642
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.1.1
>Reporter: Thomas Cunningham
>Priority: Major
> Fix For: wontfix-candidate, waiting-for-feedback
>
>
> I'm trying to work around MJAVADOC-641 and the proxy issues that we are
> having, and I'd like to set isOffline to true. I tried to do this my
> setting -Dmaven.javadoc.isOffline=true in my maven invocation, and it doesn't
> seem to take effect. Setting isOffline to true within the
> allows my build to succeed.
> Am I using the wrong command line property for isOffline?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MJAVADOC-771) Upgrade Parent to 40
[ https://issues.apache.org/jira/browse/MJAVADOC-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen reassigned MJAVADOC-771: --- Assignee: Henning Schmiedehausen > Upgrade Parent to 40 > > > Key: MJAVADOC-771 > URL: https://issues.apache.org/jira/browse/MJAVADOC-771 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Henning Schmiedehausen >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-642) Setting maven.javadoc.isoffline seems to have no effect
[ https://issues.apache.org/jira/browse/MJAVADOC-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved MJAVADOC-642. - Fix Version/s: 3.6.0 (was: waiting-for-feedback) (was: wontfix-candidate) Assignee: Henning Schmiedehausen Resolution: Fixed > Setting maven.javadoc.isoffline seems to have no effect > --- > > Key: MJAVADOC-642 > URL: https://issues.apache.org/jira/browse/MJAVADOC-642 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: jar >Affects Versions: 3.1.1 >Reporter: Thomas Cunningham >Assignee: Henning Schmiedehausen >Priority: Major > Fix For: 3.6.0 > > > I'm trying to work around MJAVADOC-641 and the proxy issues that we are > having, and I'd like to set isOffline to true. I tried to do this my > setting -Dmaven.javadoc.isOffline=true in my maven invocation, and it doesn't > seem to take effect. Setting isOffline to true within the > allows my build to succeed. > Am I using the wrong command line property for isOffline? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-771) Upgrade Parent to 40
[ https://issues.apache.org/jira/browse/MJAVADOC-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved MJAVADOC-771. - Resolution: Fixed > Upgrade Parent to 40 > > > Key: MJAVADOC-771 > URL: https://issues.apache.org/jira/browse/MJAVADOC-771 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Henning Schmiedehausen >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-752) Setting the output directory affects dependencySourceIncludes
[
https://issues.apache.org/jira/browse/MJAVADOC-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved MJAVADOC-752.
-
Assignee: Henning Schmiedehausen
Resolution: Cannot Reproduce
using the aggregate goal instead of jar fixes this.
> Setting the output directory affects dependencySourceIncludes
> -
>
> Key: MJAVADOC-752
> URL: https://issues.apache.org/jira/browse/MJAVADOC-752
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
>
> I have a large, multi-module build (github.com/jdbi/jdbi) where we build
> separate javadoc jars for all modules. These are built with a javadoc plugin
> configuration that writes the javadoc information into target/apidocs. This
> works fine.
> At the end of our build we aggregate all the separate javadoc modules into a
> single documentation site.
> This is the javadoc configuration for that:
> {{
>
> ${project.build.directory}/generated-docs/apidocs
> true
>
> org.jdbi:*
>
> Jdbi3 ${project.version} API
> Jdbi3 ${project.version} API
>
> }}
> The reactor build tries to load the included modules (org.jdbi:*) but does
> not look into the target/apidocs folder where the javadoc was written but
> from target/generated-docs/apidocs. Setting the output directory for the
> aggregation module affects the directory that the javadoc plugin uses to
> resolve the dependencySourceInclude directory.
> Expected effect: Setting the output directory only affects the place where
> the aggregated doc is written. The plugin still picks up the existing javadoc
> from the target/apidocs folders in the included modules
> Observed effect: Setting the output directory makes the plugin look at the
> wrong folders for the included moduled and does not find the existing
> documentation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGINTESTING-86) inconsistent settings injection depending on build lifecycle
Henning Schmiedehausen created MPLUGINTESTING-86:
Summary: inconsistent settings injection depending on build
lifecycle
Key: MPLUGINTESTING-86
URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-86
Project: Maven Plugin Testing
Issue Type: Improvement
Components: plugin-testing-harness
Affects Versions: 3.3.0
Reporter: Henning Schmiedehausen
How to reproduce:
Using maven 3.9.4:
{quote}
git clone g...@github.com:apache/maven-javadoc-plugin.git
cd maven-javadoc-plugin
mvn clean test -Dtest=TestJavadocReportTest ---> Success
mvn test -Dtest=TestJavadocReportTest ---> fails with NPE
{quote}
This should either consistently fail or succeed. Right now, the injection of
the "settings" field depends on what other lifecycle goals have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-733) Alternative doclet page points to an SEO spammy page
[ https://issues.apache.org/jira/browse/MJAVADOC-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763495#comment-17763495 ] Henning Schmiedehausen commented on MJAVADOC-733: - this is fixed in the code: [https://github.com/apache/maven-javadoc-plugin/blame/master/src/site/apt/examples/alternate-doclet.apt.vm#L34] Just needs the deployment for the next release. > Alternative doclet page points to an SEO spammy page > > > Key: MJAVADOC-733 > URL: https://issues.apache.org/jira/browse/MJAVADOC-733 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Critical > Fix For: 3.6.0 > > > On the page > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html > the site http://www.umlgraph.org/ is no longer valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-733) Alternative doclet page points to an SEO spammy page
[ https://issues.apache.org/jira/browse/MJAVADOC-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved MJAVADOC-733. - Resolution: Fixed > Alternative doclet page points to an SEO spammy page > > > Key: MJAVADOC-733 > URL: https://issues.apache.org/jira/browse/MJAVADOC-733 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Assignee: Henning Schmiedehausen >Priority: Critical > Fix For: 3.6.0 > > > On the page > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html > the site http://www.umlgraph.org/ is no longer valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MJAVADOC-733) Alternative doclet page points to an SEO spammy page
[ https://issues.apache.org/jira/browse/MJAVADOC-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen reassigned MJAVADOC-733: --- Assignee: Henning Schmiedehausen > Alternative doclet page points to an SEO spammy page > > > Key: MJAVADOC-733 > URL: https://issues.apache.org/jira/browse/MJAVADOC-733 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Assignee: Henning Schmiedehausen >Priority: Critical > Fix For: 3.6.0 > > > On the page > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html > the site http://www.umlgraph.org/ is no longer valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763497#comment-17763497 ] Henning Schmiedehausen commented on MJAVADOC-755: - [https://github.com/apache/maven-javadoc-plugin/pull/210] is still open. > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MJAVADOC-755: Fix Version/s: (was: 3.6.0) > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-742) [REGRESSION] Transitive dependencies of docletArtifact missing
[ https://issues.apache.org/jira/browse/MJAVADOC-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MJAVADOC-742: Fix Version/s: (was: 3.6.0) > [REGRESSION] Transitive dependencies of docletArtifact missing > -- > > Key: MJAVADOC-742 > URL: https://issues.apache.org/jira/browse/MJAVADOC-742 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.5.0 >Reporter: Patrick Ruckstuhl >Priority: Blocker > > It looks like with 3.5.0 transitive dependencies of the docletArtifact are no > longer added to the classpath and generation fails with class not found. > Reverting back to 3.4.1 everything works fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-742) [REGRESSION] Transitive dependencies of docletArtifact missing
[ https://issues.apache.org/jira/browse/MJAVADOC-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763498#comment-17763498 ] Henning Schmiedehausen commented on MJAVADOC-742: - holding off on 3.6.0 right now, the PR has not been merged because there are IT issues that need to be resolved. > [REGRESSION] Transitive dependencies of docletArtifact missing > -- > > Key: MJAVADOC-742 > URL: https://issues.apache.org/jira/browse/MJAVADOC-742 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.5.0 >Reporter: Patrick Ruckstuhl >Priority: Blocker > Fix For: 3.6.0 > > > It looks like with 3.5.0 transitive dependencies of the docletArtifact are no > longer added to the classpath and generation fails with class not found. > Reverting back to 3.4.1 everything works fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used
[
https://issues.apache.org/jira/browse/MJAVADOC-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764007#comment-17764007
]
Henning Schmiedehausen commented on MJAVADOC-707:
-
The next release of the javadoc plugin (3.6.0) will offer a new switch
(legacyMode) which should make this work for you. please try with
{{true}} either with the current snapshot or the next
release.
> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2, 3.4.0
>Reporter: Christopher Tubbs
>Priority: Critical
> Labels: jpms
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help
> transition to using modules) prevents this plugin from adding the necessary
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others
> when Automatic-Module-Name entries appear in a project's jar manifests.
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force
> treating the project as a module, even though it does not have any
> module-info.java files, and most of its dependencies have not transitioned to
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to
> the manifest for a multi-module (Maven module) project, that fails on the
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764010#comment-17764010 ] Henning Schmiedehausen commented on MJAVADOC-755: - we can add a 3.6.0 resolution version (so it shows up in the release notes) but keep the issue open (not resolve and close it). > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764009#comment-17764009 ] Henning Schmiedehausen commented on MJAVADOC-755: - works for me. > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MJAVADOC-755: Fix Version/s: 3.6.0 > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MJAVADOC-760) Cleanup dependency declarations as best possible
[ https://issues.apache.org/jira/browse/MJAVADOC-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen reassigned MJAVADOC-760: --- Assignee: Elliotte Rusty Harold > Cleanup dependency declarations as best possible > > > Key: MJAVADOC-760 > URL: https://issues.apache.org/jira/browse/MJAVADOC-760 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > > [WARNING] Used undeclared dependencies found: > [WARNING]org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.5:compile > [WARNING]org.slf4j:slf4j-api:jar:1.7.36:compile > [WARNING]org.apache.maven.shared:maven-shared-utils:jar:3.3.4:compile > [WARNING]org.eclipse.aether:aether-impl:jar:1.0.0.v20140518:provided > [WARNING]javax.servlet:javax.servlet-api:jar:3.1.0:test > [WARNING]org.hamcrest:hamcrest-core:jar:1.3:test > [WARNING]org.eclipse.aether:aether-util:jar:1.0.0.v20140518:compile > [WARNING]org.codehaus.plexus:plexus-io:jar:3.4.0:compile > [WARNING]org.codehaus.plexus:plexus-archiver:jar:4.4.0:compile > [WARNING]org.eclipse.aether:aether-api:jar:1.0.0.v20140518:compile > [WARNING]org.eclipse.jetty:jetty-util:jar:9.4.50.v20221201:test > [WARNING] Unused declared dependencies found: > [WARNING]org.eclipse.jetty:jetty-client:jar:9.4.50.v20221201:test > [WARNING] > org.eclipse.aether:aether-connector-basic:jar:1.0.0.v20140518:test > [WARNING] > org.eclipse.aether:aether-transport-wagon:jar:1.0.0.v20140518:test > [WARNING]org.apache.maven.wagon:wagon-http:jar:shaded:2.4:test > [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test > [WARNING] Non-test scoped test only dependencies found: > [WARNING]org.slf4j:slf4j-api:jar:1.7.36:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-742) [REGRESSION] Transitive dependencies of docletArtifact missing
[ https://issues.apache.org/jira/browse/MJAVADOC-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed MJAVADOC-742. --- > [REGRESSION] Transitive dependencies of docletArtifact missing > -- > > Key: MJAVADOC-742 > URL: https://issues.apache.org/jira/browse/MJAVADOC-742 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.5.0 >Reporter: Patrick Ruckstuhl >Assignee: Tamas Cservenak >Priority: Blocker > Fix For: 3.6.0 > > > It looks like with 3.5.0 transitive dependencies of the docletArtifact are no > longer added to the classpath and generation fails with class not found. > Reverting back to 3.4.1 everything works fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-733) Alternative doclet page points to an SEO spammy page
[ https://issues.apache.org/jira/browse/MJAVADOC-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed MJAVADOC-733. --- > Alternative doclet page points to an SEO spammy page > > > Key: MJAVADOC-733 > URL: https://issues.apache.org/jira/browse/MJAVADOC-733 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Assignee: Henning Schmiedehausen >Priority: Critical > Fix For: 3.6.0 > > > On the page > https://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html > the site http://www.umlgraph.org/ is no longer valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-642) Setting maven.javadoc.isoffline seems to have no effect
[ https://issues.apache.org/jira/browse/MJAVADOC-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed MJAVADOC-642. --- > Setting maven.javadoc.isoffline seems to have no effect > --- > > Key: MJAVADOC-642 > URL: https://issues.apache.org/jira/browse/MJAVADOC-642 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: jar >Affects Versions: 3.1.1 >Reporter: Thomas Cunningham >Assignee: Henning Schmiedehausen >Priority: Major > Fix For: 3.6.0 > > > I'm trying to work around MJAVADOC-641 and the proxy issues that we are > having, and I'd like to set isOffline to true. I tried to do this my > setting -Dmaven.javadoc.isOffline=true in my maven invocation, and it doesn't > seem to take effect. Setting isOffline to true within the > allows my build to succeed. > Am I using the wrong command line property for isOffline? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-769) javadoc plugin can not deal with transitive filename based modules
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed MJAVADOC-769.
---
> javadoc plugin can not deal with transitive filename based modules
> --
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.6.0
>
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
> -encoding
> 'UTF-8'
> -public
> -quiet
> --release
> 11
> -bottom
> 'Copyright © 2023. All rights reserved.'
> -charset
> 'UTF-8'
> -d
> '/Users/henning/scratch/mjavadoc769/target/apidocs'
> -docencoding
> 'UTF-8'
> -Xdoclint:none
> -doctitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> -linkoffline
> 'https://docs.oracle.com/en/java/javase/11/docs/api'
> '/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
> -nohelp
> -use
> -version
> -windowtitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> {code}
> The javadoc plugin decides that the "javax.inject-1.jar" is added to the
> classpath even though it is an optional dependency of the main module.
> Contrary to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module
> path.
> The reason for this may be that the jakarta module contains a module-info
> (hidden in META-INF/versions/9/) while the javax.inject jar does not.
> However, the checker-qual
> (org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar) dependency
> is put on the module path even though it does not contain a module-info file.
> However, it contains an {{Automatic-Module-Name}} entry in META-INF/MANIFEST.
> It seems that the javadoc plugin treats automatic dependencies with entry in
> the manifest different from automatic dependencies determined by filename.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJAVADOC-771) Upgrade Parent to 40
[ https://issues.apache.org/jira/browse/MJAVADOC-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed MJAVADOC-771. --- > Upgrade Parent to 40 > > > Key: MJAVADOC-771 > URL: https://issues.apache.org/jira/browse/MJAVADOC-771 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Henning Schmiedehausen >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-701) javadoc site is broken for projects that contain modules
[
https://issues.apache.org/jira/browse/MJAVADOC-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed MJAVADOC-701.
---
> javadoc site is broken for projects that contain modules
>
>
> Key: MJAVADOC-701
> URL: https://issues.apache.org/jira/browse/MJAVADOC-701
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.3.1
> Environment: Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.6.0
>
>
> How to reproduce:
>
> {{% git clone [https://github.com/hgschmie/pg-embedded.git]}}
> {{% cd pg-embedded}}
> {{% git checkout -b 4.0-branch pg-embedded-4.0}}
> {{% ./mvnw clean site}}
> {{% ls target/site/apidocs}}
> {{allclasses-index.html jquery-ui.overrides.css script-dir}}
> {{allpackages-index.html legal script.js}}
> {{constant-values.html member-search-index.js search.js}}
> {{de module-search-index.js src-html}}
> {{deprecated-list.html overview-summary.html stylesheet.css}}
> {{element-list overview-tree.html tag-search-index.js}}
> {{index-all.html package-search-index.js type-search-index.js}}
> {{index.html resources}}
> {{% ./mvnw clean install site}}
> {{% ls target/site/apidocs}}
> {{allclasses-index.html overview-tree.html}}
> {{allpackages-index.html package-search-index.js}}
> {{constant-values.html resources}}
> {{{color:#ff}*de.softwareforge.testing.postgres*{color} script-dir}}
> {{deprecated-list.html script.js}}
> {{element-list search.js}}
> {{index-all.html src}}
> {{index.html src-html}}
> {{jquery-ui.overrides.css stylesheet.css}}
> {{legal tag-search-index.js}}
> {{member-search-index.js type-search-index.js}}
> {{module-search-index.js}}
> ==> If the build only creates the site (run aggregate-no-fork, javadoc,
> javadoc-no-fork), it will not contain the module subfolder
> (de.softwareforge.testing.postgres)
> ==> if the build also runs the "javadoc:jar" goal, the site will contain the
> module subfolder
>
> I have looked through the debug output and the options to the maven javadoc
> plugin execution but nothing stands out. Just that one builds the module
> javadoc correctly and the other does not.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJAVADOC-760) Cleanup dependency declarations as best possible
[ https://issues.apache.org/jira/browse/MJAVADOC-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed MJAVADOC-760. --- > Cleanup dependency declarations as best possible > > > Key: MJAVADOC-760 > URL: https://issues.apache.org/jira/browse/MJAVADOC-760 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > > [WARNING] Used undeclared dependencies found: > [WARNING]org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.5:compile > [WARNING]org.slf4j:slf4j-api:jar:1.7.36:compile > [WARNING]org.apache.maven.shared:maven-shared-utils:jar:3.3.4:compile > [WARNING]org.eclipse.aether:aether-impl:jar:1.0.0.v20140518:provided > [WARNING]javax.servlet:javax.servlet-api:jar:3.1.0:test > [WARNING]org.hamcrest:hamcrest-core:jar:1.3:test > [WARNING]org.eclipse.aether:aether-util:jar:1.0.0.v20140518:compile > [WARNING]org.codehaus.plexus:plexus-io:jar:3.4.0:compile > [WARNING]org.codehaus.plexus:plexus-archiver:jar:4.4.0:compile > [WARNING]org.eclipse.aether:aether-api:jar:1.0.0.v20140518:compile > [WARNING]org.eclipse.jetty:jetty-util:jar:9.4.50.v20221201:test > [WARNING] Unused declared dependencies found: > [WARNING]org.eclipse.jetty:jetty-client:jar:9.4.50.v20221201:test > [WARNING] > org.eclipse.aether:aether-connector-basic:jar:1.0.0.v20140518:test > [WARNING] > org.eclipse.aether:aether-transport-wagon:jar:1.0.0.v20140518:test > [WARNING]org.apache.maven.wagon:wagon-http:jar:shaded:2.4:test > [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test > [WARNING] Non-test scoped test only dependencies found: > [WARNING]org.slf4j:slf4j-api:jar:1.7.36:compile -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJAVADOC-773) Clean up deprecated and unpreferred methods in JavadocUtil
Henning Schmiedehausen created MJAVADOC-773: --- Summary: Clean up deprecated and unpreferred methods in JavadocUtil Key: MJAVADOC-773 URL: https://issues.apache.org/jira/browse/MJAVADOC-773 Project: Maven Javadoc Plugin Issue Type: Improvement Reporter: Henning Schmiedehausen Assignee: Elliotte Rusty Harold Fix For: 3.6.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-773) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MJAVADOC-773: Fix Version/s: (was: 3.6.0) > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-773 > URL: https://issues.apache.org/jira/browse/MJAVADOC-773 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Henning Schmiedehausen >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen closed MJAVADOC-755. --- > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-773) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764446#comment-17764446 ] Henning Schmiedehausen commented on MJAVADOC-773: - track [https://github.com/apache/maven-javadoc-plugin/pull/210] > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-773 > URL: https://issues.apache.org/jira/browse/MJAVADOC-773 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Henning Schmiedehausen >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-755) Clean up deprecated and unpreferred methods in JavadocUtil
[ https://issues.apache.org/jira/browse/MJAVADOC-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen resolved MJAVADOC-755. - Resolution: Fixed > Clean up deprecated and unpreferred methods in JavadocUtil > -- > > Key: MJAVADOC-755 > URL: https://issues.apache.org/jira/browse/MJAVADOC-755 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-764) javadoc:aggregate fails after Java 11 upgrade
[
https://issues.apache.org/jira/browse/MJAVADOC-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-764:
Priority: Critical (was: Blocker)
> javadoc:aggregate fails after Java 11 upgrade
> --
>
> Key: MJAVADOC-764
> URL: https://issues.apache.org/jira/browse/MJAVADOC-764
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Sirisha Pratha
>Priority: Critical
> Labels: jpms
>
> We have a multi-module project that is failing for javadoc:aggregate goal
> after upgrading to Java 11 for maven-javadoc-plugin versions 3.4.1 and 3.5.0.
> It worked fine without any issues for Java 1.8.
> This is our maven-javadoc plugin configuration for Java 8 -
> {color:#00875a}*SUCCESS*{color}
>
> {noformat}
> 8
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/javase/8/docs/api/
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
>
> {noformat}
> This is our maven-javadoc plugin configuration for Java 11 - (the only
> difference is values in source and links tags) -
> *{color:#ff}FAILS{color}* {color:#ff}(See error below){color}
>
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/en/java/javase/11/docs/api
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
> {noformat}
>
> _javadoc:aggregate_ fails with the following error on our GitHub workflow
> (nothing changed in the way we run this job - we have always used Java 17 to
> run this)
>
> {noformat}
> Error: 6:236 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:aggregate (default-cli)
> on project eclipse-collections-parent: An error has occurred in Javadoc
> report generation:
> 515Error: 6:236 [ERROR] Exit code: 2 - Loading source files for package
> org.eclipse.collections.codegenerator.model...
> 516Error: 02:14:46:236 [ERROR] error: No source files for package
> org.eclipse.collections.codegenerator.model
> 517Error: 02:14:46:237 [ERROR] 1 error
> 518Error: 6:237 [ERROR]
> 519Error: 6:238 [ERROR] Command line was:
> /opt/hostedtoolcache/Java_Zulu_jdk/17.0.7-7/x64/bin/javadoc @options @packages
> 520Error: 6:238 [ERROR]
> 521Error: 6:238 [ERROR] Refer to the generated Javadoc files in
> '/home/runner/work/eclipse-collections/eclipse-collections/target/site/apidocs/12.0.0-SNAPSHOT'
> dir.
> 522Error: 6:239 [ERROR]
> 523Error: 6:240 [ERROR] -> [Help 1]{noformat}
>
>
> Solutions we tried -
> # Configuring sourcePath (see below) - in this case, *no Javadoc was
> created* in target/site/apidocs.
> {noformat}
> ${project.build.sourceDirectory}{noformat}
> # Tried both plugin versions 3.4.1 and 3.5.0 - *fails* with both versions.
> # Tried to add source = 1.8 but maven.compiler.source = 11, which seems to
> be the only combination that {*}works{*}. Like so -
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> 1.8
> Ecl
[jira] [Updated] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
[
https://issues.apache.org/jira/browse/MJAVADOC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-747:
Priority: Critical (was: Blocker)
> jar goal fails with automatic module (Regression from 3.2.0)
> -
>
> Key: MJAVADOC-747
> URL: https://issues.apache.org/jira/browse/MJAVADOC-747
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0
>Reporter: Geoffrey De Smet
>Priority: Critical
> Labels: jpms
>
> In optaplanner, we provide automatic module names for all our modules.
> But some modules have a dependency with classes in the no-name package.
> That was not a problem for the maven-javadoc-plugin, except since
> maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
> This happens with dependencies on quarkus and on rewrite.
> For example, for optaplanner-migrator that depends on rewrite-maven and
> rewrite-gradle:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
> reproducer:
> Execution default of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
> Unable to derive module descriptor for
> /.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
> PluginSpec.class found in top-level directory (unnamed package not allowed in
> module) -> [Help 1]{code}
> Isolated reproducer:
> [https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7888) maven releases do not resolve URL in pom
Henning Schmiedehausen created MNG-7888:
---
Summary: maven releases do not resolve URL in pom
Key: MNG-7888
URL: https://issues.apache.org/jira/browse/MNG-7888
Project: Maven
Issue Type: Bug
Reporter: Henning Schmiedehausen
The released poms contain
{{https://github.com/apache/maven-javadoc-plugin/tree/${project.scm.tag}}}.
As a result, tools that do not actively parse and resolve the pom can't
display a valid URL but only show a link with the placeholder.
E.g.
https://search.maven.org/artifact/org.apache.maven.plugins/maven-javadoc-plugin/3.4.1/maven-plugin
This seems to be a fundamental problem with the maven parent pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7888) maven releases do not resolve URL in pom
[
https://issues.apache.org/jira/browse/MNG-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766034#comment-17766034
]
Henning Schmiedehausen commented on MNG-7888:
-
then what is the point of having metadata such as doc urls, issue tracker etc.
if they can't be read outside a maven context? We could pretend that the maven
universe is hermetic and only the maven driven tooling exists (e.g. site
generation).
The real world looks different. Case in point are the URIs above. Most projects
get this right (they fully resolve the pom before publishing).
> maven releases do not resolve URL in pom
> -
>
> Key: MNG-7888
> URL: https://issues.apache.org/jira/browse/MNG-7888
> Project: Maven
> Issue Type: Bug
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> The released poms contain
> {{https://github.com/apache/maven-javadoc-plugin/tree/${project.scm.tag}}}.
> As a result, tools that do not actively parse and resolve the pom can't
> display a valid URL but only show a link with the placeholder.
> E.g.
> https://search.maven.org/artifact/org.apache.maven.plugins/maven-javadoc-plugin/3.4.1/maven-plugin
> This seems to be a fundamental problem with the maven parent pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2191) surefire crashes on a JPMS modularized project that uses junit5
[
https://issues.apache.org/jira/browse/SUREFIRE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766043#comment-17766043
]
Henning Schmiedehausen commented on SUREFIRE-2191:
--
I have two modules, core and testing (these are defined modules, they have a
module descriptor)
"core" is just a regular build, it uses junit5 as its test framework.
surefire creates a classpath with all the surefire deps (surefire-api,
surefire-extensions, surefire-junit-platform, surefire-logging-api,
surefire-shared-utils) and the junit deps (junit-jupiter-api,
junit-jupiter-engine, junit-jupiter-params, junit-platform-commons,
junit-platform-engine, junit-platform-launcher). The module path only gets the
actual module dependencies of module A
All works well in that case.
Now the "testing" module declares org.junit.jupiter.api as a dependency and has
requires org.junit.jupiter.api in its module descriptor (transitive or not
transitive does not matter) because there is code that implements some of those
APIs.
surefire now creates a classpath with the same surefire deps and only a subset
of junit deps. The missing deps (junit-jupiter-api and junit-platform-commons)
are pulled onto the module path.
This explains the error message:
*java.lang.IllegalAccessError: class
org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder (in unnamed
module @0x6392827e) cannot access class
org.junit.platform.commons.util.Preconditions (in module
org.junit.platform.commons) because module org.junit.platform.commons does not
export org.junit.platform.commons.util to unnamed module @0x6392827e*
The launcher (in junit-platform-launcher) lives on the classpath and is
therefore in the unnamed module. But the launcher requires the
org.junit.platform.commons module from the junit-platform-commons jar, which is
on the module path. And the junit-platform-commons module has the following
clause in its module descriptor:
exports org.junit.platform.commons.util to
[...]
org.junit.platform.launcher,
[...];
and it does not export the package to the unnamed module. And now JVM fails
with the error above.
I can not see any good solution:
- The current solution does not work (see above)
- The junit-jupiter-api which contains org.junit.jupiter.api can not go on the
class path because now the main artifact which requires it can not find it.
- It can not be patched into the main module because now the
org.junit.jupiter.api module would be invisible to everything on the module
path (packages can't exist twice)
- It can only stay on the module path if everything that depends on it gets
pulled there as well. This requires a "bottom up" resolution of all modules
that depend on this (in this case org.junit.jupiter.api) and may interfere with
the ability of the surefire launcher to launch code.- We could fall back to
"legacy" mode where everything is on the classpath and the module path is
ignored. This is problematic as tests may pass and code later fails because of
not matching entries in the module descriptor
> surefire crashes on a JPMS modularized project that uses junit5
> ---
>
> Key: SUREFIRE-2191
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2191
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, process forking
>Affects Versions: 3.1.2
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: [https://github.com/hgschmie/surefire-2191
> |https://github.com/hgschmie/surefire-2191] and build it.
> The build fails during testing with a large and cryptic error description.
> The code only uses the junit jupiter APIs and imports the with {{ requires
> transitive org.junit.jupiter.api;}}
> This is the surefireargs file that the plugin creates:
> {code}
> --module-path
> "/Users/henning/scratch/surefire-junit-bug/target/classes:/Users/henning/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.10.0/junit-jupiter-api-5.10.0.jar:/Users/henning/.m2/repository/org/opentest4j/opentest4j/1.3.0/opentest4j-1.3.0.jar:/Users/henning/.m2/repository/org/junit/platform/junit-platform-commons/1.10.0/junit-platform-commons-1.10.0.jar:/Users/henning/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar"
> --class-path
> "/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-api/3.1.2/surefire-api-3.1.2.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-booter/3.1.2/surefire-booter-3.1.2.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-extensions-spi/3.1.2/surefire-extensions-spi-3.1.2.jar:/Users/henning/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.1.2/surefire-logger-api-3.1.2.jar:/Users/henning/.m2/repository
[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used
[ https://issues.apache.org/jira/browse/MJAVADOC-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766044#comment-17766044 ] Henning Schmiedehausen commented on MJAVADOC-707: - *happy dance* Can we close this issue in this case? > Plugin won't work if Automatic-Module-Name is used > -- > > Key: MJAVADOC-707 > URL: https://issues.apache.org/jira/browse/MJAVADOC-707 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.3.1, 3.3.2, 3.4.0 >Reporter: Christopher Tubbs >Priority: Critical > Labels: jpms > > Using Automatic-Module-Name in a manifest (an intermediate step to help > transition to using modules) prevents this plugin from adding the necessary > dependencies to the class path, so it can build javadocs. > maven-compiler-plugin seems to work fine, as does surefire and all the others > when Automatic-Module-Name entries appear in a project's jar manifests. > However, this plugin, as of 3.3.1, still does not work correctly with these. > Instead of using the traditional class path, this plugin seems to force > treating the project as a module, even though it does not have any > module-info.java files, and most of its dependencies have not transitioned to > using modules. > Here's a pull request that demonstrates adding the Automatic-Module-Name to > the manifest for a multi-module (Maven module) project, that fails on the > javadoc plugin: > https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and > javadoc:jar are known to fail. I did not test with any other mojos. > Not supporting this feature holds all projects back from being able to > transition to modules over time. > http://branchandbound.net/blog/java/2017/12/automatic-module-name/ > https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-548) JDK 21 throws annotations processing warning that can not be turned off
Henning Schmiedehausen created MCOMPILER-548:
Summary: JDK 21 throws annotations processing warning that can not
be turned off
Key: MCOMPILER-548
URL: https://issues.apache.org/jira/browse/MCOMPILER-548
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.11.0
Reporter: Henning Schmiedehausen
maven compiler plugin 3.11 on Java 21 reports
{quote}
[INFO] Annotation processing is enabled because one or more processors were
found
on the class path. A future release of javac may disable annotation processing
unless at least one processor is specified by name (-processor), or a search
path is specified (--processor-path, --processor-module-path), or annotation
processing is enabled explicitly (-proc:only, -proc:full).
Use -Xlint:-options to suppress this message.
Use -proc:none to disable annotation processing.
{quote}
However, the {{}} option only supports "none" and "proc", not "full"
(which is the implicit default).
Adding this through a compiler option:
{quote}
-proc:full
{quote}
fixes this warning. Adding "full" as a value for the compiler plugin would fix
it, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7787) Introduce new options for plugin validation
[ https://issues.apache.org/jira/browse/MNG-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791229#comment-17791229 ] Henning Schmiedehausen commented on MNG-7787: - I closed it. > Introduce new options for plugin validation > --- > > Key: MNG-7787 > URL: https://issues.apache.org/jira/browse/MNG-7787 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-7, 4.0.0 > > > Currently we offer following values for maven.plugin.validation: > * BRIEF - emits one liner WARN with count of plugins having validation > issues (IF count > 0) > * DEFAULT - emits one line for each plugin GAV having validation issues > * VERBOSE - emits detailed report for each plugin (declaration, use and > problems) for each plugin having validation issue > We should introduce more: > * NONE - mute validation (usable on CI where plethora of WARNING lines could > lead to falsely detect build as unhealthy) > * INLINE - produce validation WARNs inline, as 3.9.1 did > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812527#comment-17812527
]
Henning Schmiedehausen commented on MNG-7906:
-
[~cstamas] pinged me on [https://github.com/basepom/maven-plugins/issues/10]
FWIW, I am very much with [~elharo]. The current behavior exists for close to
20 years and changing it would break large parts of the ecosystem.
Frankly, the fact that there are multiple ways to do dep resolution over the
years, the ever-changing nature of the maven resolver and the complicated and
under-documented way to access repositories make it hard for maven users to get
this right and near impossible for plugin writers to builds something that
matches the core behavior.
"effective pom" is not a debugging tool for the faint of heart. running it on a
major project makes it near impossible to understand its output.
If you want a tool that actually works for humans, try
[https://github.com/basepom/dependency-versions-check-maven-plugin]
It produces output like this:
{{[INFO] All dependencies for 'compile' scope:}}
{{[INFO] com.fasterxml.jackson.core:jackson-annotations: compile 2.13.4
(2.10.3)}}
{{[INFO] com.github.docker-java:docker-java-api: compile 3.2.13}}
{{[INFO] com.github.docker-java:docker-java-transport: compile 3.2.13}}
{{[INFO] com.github.docker-java:docker-java-transport-zerodep: compile 3.2.13}}
{{[INFO] com.google.code.findbugs:jsr305: compile 1.3.9}}
{{[INFO] junit:junit: compile 4.13.2}}
{{[INFO] net.bytebuddy:byte-buddy: compile 1.10.14 (!1.12.10!)}}
{{[INFO] net.java.dev.jna:jna: compile 5.8.0}}
{{[INFO] org.apache.commons:commons-compress: compile 1.21}}
{{[INFO] org.apache.flink:flink-shaded-force-shading: compile 16.2}}
{{[INFO] org.apache.logging.log4j:log4j-api: compile 2.17.1}}
{{[INFO] org.apache.logging.log4j:log4j-core: compile 2.17.1}}
{{[INFO] org.apache.logging.log4j:log4j-slf4j-impl: compile 2.17.1}}
{{[INFO] org.apiguardian:apiguardian-api: compile 1.1.2}}
{{[INFO] org.assertj:assertj-core: compile 3.23.1}}
{{[INFO] org.jetbrains:annotations: compile 17.0.0}}
{{[INFO] org.junit.jupiter:junit-jupiter: compile 5.9.1}}
{{[INFO] org.junit.jupiter:junit-jupiter-api: compile 5.9.1}}
{{[INFO] org.junit.jupiter:junit-jupiter-params: compile 5.9.1}}
{{[INFO] org.junit.platform:junit-platform-commons: compile 1.9.1 (1.8.2)}}
{{[INFO] org.junit.platform:junit-platform-engine: compile 1.9.1}}
{{[INFO] org.junit.vintage:junit-vintage-engine: compile 5.9.1}}
{{[INFO] org.opentest4j:opentest4j: compile 1.2.0}}
{{[INFO] org.rnorth.duct-tape:duct-tape: compile 1.0.8}}
{{[INFO] org.slf4j:slf4j-api: compile 1.7.36 (1.7.25, 1.7.35)}}
{{[INFO] org.testcontainers:testcontainers: compile 1.17.2}}
which users can actually use to figure out what is wrong with their build. It
does approximate what the resolver does (and there is no way for me to actually
validate that it matches the core behavior).
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812528#comment-17812528
]
Henning Schmiedehausen commented on MNG-7906:
-
the major problem of each of these resolver discussions is BTW summarized on
this page:
[https://basepom.github.io/dependency-versions-check-maven-plugin/development/]
*Apache Maven operates under the assumption that every dependency is always
backwards compatible and when two versions are compared, using the “higher”
version will satisfy any dependency.*
As long as this assumption is baked into maven (IAW, replacing "0.0.1" with
"1.0.0" is fine) and maven does not fail as soon as it finds two different
versions of the same dependency referenced in the dependency tree (with
subsequent human input to decide whether two versions for a given artifact are
compatible or not), I see no real point to discuss how dependency resolution
should work and which version should "win".
Other ecosystems have e.g. baked Semantic versioning into their dependency
model. Java/Maven has not (because it predates it by years).
Unless Maven starts encouraging (enforcing?) artifacts to create a version
policy (e.g. "this artifact follows semantic versioning") and maven can consume
that and behave accordingly, I am not sure why we try to "fix" the resolve
behavior. The best bet IMHO is to simply accept that we have settled on the way
the resolver works today, the maven users rely on it and stop trying to improve
it.
e.g. semantic versioning would mean that you can NOT replace 1.0.0 with 2.0.0.
Which maven happily does today.
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
