[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832262#comment-17832262 ] Henning Schmiedehausen commented on MRESOLVER-391: -- If the problem described in MNG-8041 can not be fixed for Maven 3/4 for backwards compatibility, wouldn't it be possible to have a flag or config option in the pom where my project can "opt in" to the correct/new behavior? The challenge with "being backwards compatible at any cost" means that there is no progress. I am totally willing to test-drive/fix my builds if a change breaks it, if I can *opt into* the change at my own pace and don't get it forced on me. If this is a property that one can set in the pom (`legacy|modern|`), I am sure that a lot of projects would want to try this out/adopt it. Right now, we all do various workarounds to keep our builds working and would love to get rid of the rather sooner than later, even if that means to rewrite my builds. Thanks to the maven wrapper, I can ship a "working maven version" with my project so I no longer need to care about "what version of maven the user has installed". Please consider having an optional "here is the full fix, expect things to break, you can activate it with this flag" option for maven 3 and 4. (and please make it part of the pom, not a command line option :) ) > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
[ https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832006#comment-17832006 ] Henning Schmiedehausen commented on MJAR-300: - I ended up using the maven archiver parsing code and then pass the timestamp into my code. This should be most compatible and seems to work fine - [https://github.com/basepom/inline-maven-plugin/blob/main/plugin/src/main/java/org/basepom/inline/mojo/InlineMojo.java#L278] > maven jar plugin does not interpret build outputTimestamp correctly > --- > > Key: MJAR-300 > URL: https://issues.apache.org/jira/browse/MJAR-300 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Priority: Major > > consider a minimal project that packages a jar: > % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:44:53-08:00 > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ > 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt > 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sat Feb 10 21:44:54 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > Note how the timestamp returned by the date command and the timestamps of the > entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb > 10th, 2024) > Now use that date as the project build timestamp: > DATE=$(date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:46:30-08:00 > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ > 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt > 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:46:30 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > > The timestamp and the entries in the jar differ by eight hours (the offset of > my local timezone). > When forcing UTC: > DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-11T05:48:22+00:00 > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ > 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt > 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:48:22 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > The timestamp is "correct" but I passed it in as UTC but the jar plugin > considers it "local time" and silently attaches PST as timezone. This is > where the eight hours discrepancy come from. > This seems to be specific to the outputTimestamp parsing of the jar plugin. > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1141) maven release plugin overwrites project.build.outputTimestamp value
[
https://issues.apache.org/jira/browse/MRELEASE-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17819036#comment-17819036
]
Henning Schmiedehausen commented on MRELEASE-1141:
--
We don't ship source tarballs and the only way to validate our builds is to git
clone, checkout the tag and run clean verify artifact:compare
It would be good to address the problem (plugin overrides a setting and there
should be a way to avoid that).
> maven release plugin overwrites project.build.outputTimestamp value
> ---
>
> Key: MRELEASE-1141
> URL: https://issues.apache.org/jira/browse/MRELEASE-1141
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.1
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> I am using
> {{${git.commit.time}}}
> as the setting for reproducible timestamps to use the git timestamp as the
> timestamp for the reproducible build.
> When running "release:prepare", the plugin replaces this property reference
> with an actual timestamp, thus my setting gets lost. I am not interested in
> having a value there, I'd like to use the git timestamp.
> There seems to be no setting to not clobber this value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRELEASE-1141) maven release plugin overwrites project.build.outputTimestamp value
Henning Schmiedehausen created MRELEASE-1141:
Summary: maven release plugin overwrites
project.build.outputTimestamp value
Key: MRELEASE-1141
URL: https://issues.apache.org/jira/browse/MRELEASE-1141
Project: Maven Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 3.0.1
Reporter: Henning Schmiedehausen
I am using
{{${git.commit.time}}}
as the setting for reproducible timestamps to use the git timestamp as the
timestamp for the reproducible build.
When running "release:prepare", the plugin replaces this property reference
with an actual timestamp, thus my setting gets lost. I am not interested in
having a value there, I'd like to use the git timestamp.
There seems to be no setting to not clobber this value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
[ https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816841#comment-17816841 ] Henning Schmiedehausen commented on MJAR-300: - Thanks for the response. This is not what I meant; I was asking for "how can I emulate the behavior of the maven archiver?". Right now, it creates different, stable, timestamps for the same project.build.outputTimestamp value, see the example above: 0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr-reproducible/ 81 Sat Feb 10 23:37:52 PST 2024 META-INF/MANIFEST.MF The timestamp in the first line is created by a plugin that repackages other jars. The second is from a jar that was created in the same build, right before repackaging. The jar plugin creates the "23:37:52" timestamp, my current code (which I outlined above) creates the "15:37:52" timestamp. I'd like for those to be the same but I am not sure where this goes awry. > maven jar plugin does not interpret build outputTimestamp correctly > --- > > Key: MJAR-300 > URL: https://issues.apache.org/jira/browse/MJAR-300 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Priority: Major > > consider a minimal project that packages a jar: > % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:44:53-08:00 > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ > 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt > 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sat Feb 10 21:44:54 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > Note how the timestamp returned by the date command and the timestamps of the > entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb > 10th, 2024) > Now use that date as the project build timestamp: > DATE=$(date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:46:30-08:00 > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ > 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt > 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:46:30 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > > The timestamp and the entries in the jar differ by eight hours (the offset of > my local timezone). > When forcing UTC: > DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-11T05:48:22+00:00 > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ > 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt > 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:48:22 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > The timestamp is "correct" but I passed it in as UTC but the jar plugin > considers it "local time" and silently attaches PST as timezone. This is > where the eight hours discrepancy come from. > This seems to be specific to the outputTimestamp parsing of the jar plugin. > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
[ https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816696#comment-17816696 ] Henning Schmiedehausen commented on MJAR-300: - [~hboutemy] I looked at the code in maven-archiver, but I am reluctant to use the archiver; right now I have pretty simple code with a JarOutputStream and writing JarEntry objects into the stream. I am using the maven archiver code to parse the output timestamp ([https://github.com/basepom/inline-maven-plugin/blob/main/plugin/src/main/java/org/basepom/inline/mojo/InlineMojo.java#L278)] and use Instant#toEpochMillis() to write the timestamp. This produces a different result than the maven archiver "configureReproducibleBuild" ([https://maven.apache.org/shared/maven-archiver/apidocs/org/apache/maven/archiver/MavenArchiver.html#configureReproducibleBuild(java.lang.String)).] What would be your recommendation? I have no plans to use the JarArchiver or the complex plexus code. Could we document what plugin writers are *supposed* to do? The current behavior seems weird, I am using only standard Java APIs in the most obvious way and that produces a different result than the archiver code. (parse Timestamp with maven-archiver -> Instant -> Instant.toEpochMillis() (which is millis since the epoch in GMT) -> ZipEntry#setTime). Would it make more sense to use setLastModifiedTime here (which takes a FileTime)? Also, it would be good to document how the timestamps in the jar are derived when project.build.outputTimestamp is set. I found next to no documentation besides code. > maven jar plugin does not interpret build outputTimestamp correctly > --- > > Key: MJAR-300 > URL: https://issues.apache.org/jira/browse/MJAR-300 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Priority: Major > > consider a minimal project that packages a jar: > % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:44:53-08:00 > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ > 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt > 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sat Feb 10 21:44:54 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > Note how the timestamp returned by the date command and the timestamps of the > entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb > 10th, 2024) > Now use that date as the project build timestamp: > DATE=$(date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:46:30-08:00 > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ > 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt > 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:46:30 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > > The timestamp and the entries in the jar differ by eight hours (the offset of > my local timezone). > When forcing UTC: > DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-11T05:48:22+00:00 > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ > 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt > 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:48:22 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > The timestamp is "correct" but I passed it in as UTC but the jar plugin > considers it "local time" and silently attaches PST as timezone. This is > where the eight hours discrepancy come from. > This seems to be specific to the outputTimestamp parsing of the jar plugin. > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
[ https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816452#comment-17816452 ] Henning Schmiedehausen commented on MJAR-300: - the fourth example just reinforces what I wrote: 15:18 -05:00 == 20:18 UTC (b/c America/New_York is five hours behind UTC) and the timestamp in the archive is shown with PST, so it turns into "20:18 PST". > maven jar plugin does not interpret build outputTimestamp correctly > --- > > Key: MJAR-300 > URL: https://issues.apache.org/jira/browse/MJAR-300 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Priority: Major > > consider a minimal project that packages a jar: > % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:44:53-08:00 > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ > 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt > 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sat Feb 10 21:44:54 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > Note how the timestamp returned by the date command and the timestamps of the > entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb > 10th, 2024) > Now use that date as the project build timestamp: > DATE=$(date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:46:30-08:00 > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ > 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt > 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:46:30 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > > The timestamp and the entries in the jar differ by eight hours (the offset of > my local timezone). > When forcing UTC: > DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-11T05:48:22+00:00 > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ > 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt > 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:48:22 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > The timestamp is "correct" but I passed it in as UTC but the jar plugin > considers it "local time" and silently attaches PST as timezone. This is > where the eight hours discrepancy come from. > This seems to be specific to the outputTimestamp parsing of the jar plugin. > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
[ https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816451#comment-17816451 ] Henning Schmiedehausen commented on MJAR-300: - In your second example: 2024-02-11T10:46:07+01:00 0 Sun Feb 11 09:46:06 CET 2024 META-INF/ There is a one hour difference between those two values (10:46:xx +01:00 is *NOT* 09:46:xx CET) In your third example: 2024-02-11T09:46:43+00:00 0 Sun Feb 11 09:46:42 CET 2024 META-INF/ There is a timezone shift here (+00:00 is *NOT* CET) your fourth example I could not reproduce: DATE=$(TZ=America/New_York date -Iseconds) ; echo $DATE ; TZ=America/New_York mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar 2024-02-11T15:18:32-05:00 0 Sun Feb 11 20:18:32 PST 2024 META-INF/ 699 Sun Feb 11 20:18:32 PST 2024 META-INF/MANIFEST.MF 0 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/ 0 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/jartest/ 0 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/jartest/jartest/ 5 Sun Feb 11 20:18:32 PST 2024 testfile.txt 575 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/jartest/jartest/pom.xml 56 Sun Feb 11 20:18:32 PST 2024 META-INF/maven/jartest/jartest/pom.properties This still produces an archive with timestamps in my local timezone and 15:18-05:00 would be 12:18-08:00 (PST), we are three hours behind. So the results make even less sense (why would a timestamp of 15:18-05:00 end up being 20:18-08:00?) You literally reproduced the problem in your second and third example with the evidence visible. > maven jar plugin does not interpret build outputTimestamp correctly > --- > > Key: MJAR-300 > URL: https://issues.apache.org/jira/browse/MJAR-300 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Priority: Major > > consider a minimal project that packages a jar: > % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:44:53-08:00 > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ > 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt > 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sat Feb 10 21:44:54 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > Note how the timestamp returned by the date command and the timestamps of the > entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb > 10th, 2024) > Now use that date as the project build timestamp: > DATE=$(date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:46:30-08:00 > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ > 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt > 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:46:30 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > > The timestamp and the entries in the jar differ by eight hours (the offset of > my local timezone). > When forcing UTC: > DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-11T05:48:22+00:00 > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ > 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt > 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:48:22 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > The timestamp is "correct" but I passed it in as UTC but the jar plugin > considers it "local time" and silently attaches PST as timezone. This is > where the eight hours discrepancy come from. > This seems to be specific to the outputTimestamp parsing of the jar plugin. > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
[
https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816369#comment-17816369
]
Henning Schmiedehausen commented on MJAR-300:
-
This is a major (borderline blocking) bug for me as I have code that repackages
jars. Without output timestamps, my repackaged jars look like this:
jar tvf plugin/target/it/test-antlr/target/test-antlr-1.0.under-test.jar |
grep META-INF
0 Sat Feb 10 21:31:20 PST 2024 META-INF/
0 Sat Feb 10 21:31:20 PST 2024 META-INF/inlined/
0 Sat Feb 10 21:31:20 PST 2024 META-INF/inlined/org.antlr/
0 Sat Feb 10 21:31:20 PST 2024 META-INF/inlined/org.antlr/antlr4-runtime/
0 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/
0 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/org.antlr/
0 Sat Feb 10 21:31:20 PST 2024 META-INF/maven/org.antlr/antlr4-runtime/
0 Sat Feb 10 21:31:20 PST 2024
META-INF/maven/org.basepom.maven.inline-maven-plugin/
0 Sat Feb 10 21:31:20 PST 2024
META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr/
81 Sat Feb 10 21:31:20 PST 2024 META-INF/MANIFEST.MF
2607 Sat Feb 10 21:31:12 PST 2024
META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr/pom.xml
91 Sat Feb 10 21:31:20 PST 2024
META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr/pom.properties
The last three lines of the jar come from the original jar, the first block is
generated by the repackager.
With an output timestamp , this happens:
jar tvf
plugin/target/it/test-antlr-reproducible/target/test-antlr-reproducible-1.0.under-test.jar
| grep META-INF
0 Sat Feb 10 15:37:52 PST 2024 META-INF/
0 Sat Feb 10 15:37:52 PST 2024 META-INF/inlined/
0 Sat Feb 10 15:37:52 PST 2024 META-INF/inlined/org.antlr/
0 Sat Feb 10 15:37:52 PST 2024 META-INF/inlined/org.antlr/antlr4-runtime/
0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/
0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/org.antlr/
0 Sat Feb 10 15:37:52 PST 2024 META-INF/maven/org.antlr/antlr4-runtime/
0 Sat Feb 10 15:37:52 PST 2024
META-INF/maven/org.basepom.maven.inline-maven-plugin/
0 Sat Feb 10 15:37:52 PST 2024
META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr-reproducible/
81 Sat Feb 10 23:37:52 PST 2024 META-INF/MANIFEST.MF
2717 Sat Feb 10 23:37:52 PST 2024
META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr-reproducible/pom.xml
104 Sat Feb 10 23:37:52 PST 2024
META-INF/maven/org.basepom.maven.inline-maven-plugin/test-antlr-reproducible/pom.properties
The first block (generated by my code) has the correct timestamp. The last
three lines (which come from a jar that was packaged with the maven-jar-plugin
3.3.0) do not. The timestamp is set by a property in the pom.
{*}technically{*}, this is a reproducible build. But it has a wrong,
reproducible value (in fact every jar ever packaged with the jar plugin has
wrong timestamps).
> maven jar plugin does not interpret build outputTimestamp correctly
> ---
>
> Key: MJAR-300
> URL: https://issues.apache.org/jira/browse/MJAR-300
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> consider a minimal project that packages a jar:
> % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf
> target/jartest-0.1-SNAPSHOT.jar
> 2024-02-10T21:44:53-08:00
> 0 Sat Feb 10 21:44:54 PST 2024 META-INF/
> 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF
> 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/
> 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/
> 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/
> 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt
> 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml
> 56 Sat Feb 10 21:44:54 PST 2024
> META-INF/maven/jartest/jartest/pom.properties
> Note how the timestamp returned by the date command and the timestamps of the
> entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb
> 10th, 2024)
> Now use that date as the project build timestamp:
> DATE=$(date -Iseconds) ; echo $DATE ; mvn -q
> -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf
> target/jartest-0.1-SNAPSHOT.jar
> 2024-02-10T21:46:30-08:00
> 0 Sun Feb 11 05:46:30 PST 2024 META-INF/
> 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF
> 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/
> 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/
> 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/
> 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt
> 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml
> 56 Sun Feb 11 05
[jira] [Commented] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
[ https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816368#comment-17816368 ] Henning Schmiedehausen commented on MJAR-300: - I can track this down to this line in plexus-archiver: [https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1090] the correct Instant is passed into the method, then the JarArchiver instance ultimately delegates to the AbstractZipArchiver code here: [https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L689-L694 |https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L689-L694]which assumes that the timestamp is "millis since the epoch in the local timezone". However, the code calling this is passing in "millis since the epoch in UTC" after having converted the timestamp with timezone into UTC first. this explains the "hours offset from UTC" discrepancy between the timestamp and the actual entries in the jar. There is ambiguity between the plexus Archiver#configureReproducibleBuild(FileTime lastModifiedTime) method and the implementation in the AbstractZipArchiver. While the former seems to require the correct timezone, the latter, at least in the zip archiver case, seems to ignore it. > maven jar plugin does not interpret build outputTimestamp correctly > --- > > Key: MJAR-300 > URL: https://issues.apache.org/jira/browse/MJAR-300 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Priority: Major > > consider a minimal project that packages a jar: > % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:44:53-08:00 > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ > 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt > 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sat Feb 10 21:44:54 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > Note how the timestamp returned by the date command and the timestamps of the > entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb > 10th, 2024) > Now use that date as the project build timestamp: > DATE=$(date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:46:30-08:00 > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ > 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt > 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:46:30 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > > The timestamp and the entries in the jar differ by eight hours (the offset of > my local timezone). > When forcing UTC: > DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-11T05:48:22+00:00 > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ > 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt > 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:48:22 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > The timestamp is "correct" but I passed it in as UTC but the jar plugin > considers it "local time" and silently attaches PST as timezone. This is > where the eight hours discrepancy come from. > This seems to be specific to the outputTimestamp parsing of the jar plugin. > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
[ https://issues.apache.org/jira/browse/MJAR-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816367#comment-17816367 ] Henning Schmiedehausen commented on MJAR-300: - repo: https://github.com/hgschmie/MJAR-300 > maven jar plugin does not interpret build outputTimestamp correctly > --- > > Key: MJAR-300 > URL: https://issues.apache.org/jira/browse/MJAR-300 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Henning Schmiedehausen >Priority: Major > > consider a minimal project that packages a jar: > % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:44:53-08:00 > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ > 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ > 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt > 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sat Feb 10 21:44:54 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > Note how the timestamp returned by the date command and the timestamps of the > entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb > 10th, 2024) > Now use that date as the project build timestamp: > DATE=$(date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-10T21:46:30-08:00 > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ > 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt > 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:46:30 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > > The timestamp and the entries in the jar differ by eight hours (the offset of > my local timezone). > When forcing UTC: > DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q > -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf > target/jartest-0.1-SNAPSHOT.jar > 2024-02-11T05:48:22+00:00 > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ > 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ > 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ > 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt > 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml > 56 Sun Feb 11 05:48:22 PST 2024 > META-INF/maven/jartest/jartest/pom.properties > The timestamp is "correct" but I passed it in as UTC but the jar plugin > considers it "local time" and silently attaches PST as timezone. This is > where the eight hours discrepancy come from. > This seems to be specific to the outputTimestamp parsing of the jar plugin. > > > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJAR-300) maven jar plugin does not interpret build outputTimestamp correctly
Henning Schmiedehausen created MJAR-300: --- Summary: maven jar plugin does not interpret build outputTimestamp correctly Key: MJAR-300 URL: https://issues.apache.org/jira/browse/MJAR-300 Project: Maven JAR Plugin Issue Type: Bug Affects Versions: 3.3.0 Reporter: Henning Schmiedehausen consider a minimal project that packages a jar: % DATE=$(date -Iseconds) ; echo $DATE ; mvn -q clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar 2024-02-10T21:44:53-08:00 0 Sat Feb 10 21:44:54 PST 2024 META-INF/ 568 Sat Feb 10 21:44:54 PST 2024 META-INF/MANIFEST.MF 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/ 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/ 0 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/ 5 Sat Feb 10 21:44:54 PST 2024 testfile.txt 575 Sat Feb 10 21:39:50 PST 2024 META-INF/maven/jartest/jartest/pom.xml 56 Sat Feb 10 21:44:54 PST 2024 META-INF/maven/jartest/jartest/pom.properties Note how the timestamp returned by the date command and the timestamps of the entries in the jar are basically the same (around 21:44:53 - 21:44:54 on Feb 10th, 2024) Now use that date as the project build timestamp: DATE=$(date -Iseconds) ; echo $DATE ; mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar 2024-02-10T21:46:30-08:00 0 Sun Feb 11 05:46:30 PST 2024 META-INF/ 568 Sun Feb 11 05:46:30 PST 2024 META-INF/MANIFEST.MF 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/ 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/ 0 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/ 5 Sun Feb 11 05:46:30 PST 2024 testfile.txt 575 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.xml 56 Sun Feb 11 05:46:30 PST 2024 META-INF/maven/jartest/jartest/pom.properties The timestamp and the entries in the jar differ by eight hours (the offset of my local timezone). When forcing UTC: DATE=$(TZ=UTC date -Iseconds) ; echo $DATE ; mvn -q -Dproject.build.outputTimestamp=$DATE clean package ; jar tvf target/jartest-0.1-SNAPSHOT.jar 2024-02-11T05:48:22+00:00 0 Sun Feb 11 05:48:22 PST 2024 META-INF/ 568 Sun Feb 11 05:48:22 PST 2024 META-INF/MANIFEST.MF 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/ 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/ 0 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/ 5 Sun Feb 11 05:48:22 PST 2024 testfile.txt 575 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.xml 56 Sun Feb 11 05:48:22 PST 2024 META-INF/maven/jartest/jartest/pom.properties The timestamp is "correct" but I passed it in as UTC but the jar plugin considers it "local time" and silently attaches PST as timezone. This is where the eight hours discrepancy come from. This seems to be specific to the outputTimestamp parsing of the jar plugin. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814414#comment-17814414 ] Henning Schmiedehausen commented on MRESOLVER-391: -- Well, that was a journey from "I have a feeling this/these issues is/are NOT resolver issues (it seems fine), but a _series of bugs_ in some of plugins". Proves again, that you should never trust your feelings. :) > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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=17813854#comment-17813854
]
Henning Schmiedehausen edited comment on MNG-7906 at 2/2/24 11:34 PM:
--
[~cstamas] you literally made my point. I was not about "highest version wins"
(I wrote that but it is incorrect as you pointed out). My main point is that
maven works under the assumption that every version is always backwards
compatible to each other.
If you have a dependency A that uses library "1.0.0" and then add that library
to your pom with version "2.0.0", you end up with "2.0.0". And that is
{*}wrong{*}. The build should *fail.* Because there is no guarantee that you
can replace 1.0.0 with 2.0.0.
The other way around is worse: if you have a library that declares a dependency
"1.1.0" and then you use the "1.0.0" dependency, you downgrade a transitive
dependency with a non-compatible version.
This behavior is the sole reason why the dvc plugin exists.
I very much heard the point that this statement is incorrect, but not because
"best wins" but "nearest wins". So let me rephrase that (and I will update the
plugin pages) :
*Apache Maven operates under the assumption that it can replace any dependency
version with any other version based on a "closest to the root wins" algorithm,
that makes it almost impossible to predict which version of a dependency will
end up in the build unless all used dependencies are locked down (e.g. by
adding entries and the resulting build tree is analyzed
to ensure that the different packages end up with versions that are compatible.
Maven has no builtin concept of backward or forward compatible versions, it
assumes that every version can be replaced with any other version based on this
"nearest is best" algorithm and the resulting tree still makes sense.*
Not sure that this makes your life easier or better. Let me know if you can
agree or disagree that this statement reflects reality better.
My *recommendation* would be that we start adopting an actual compatibility
policy (semantic versioning seems to have won) but allow projects to override
that policy (maybe with a new element in the POM; 4.0.0 may be a good
opportunity). But the current behavior is so poorly understood that people are
bound to get it wrong. I got it wrong. :)
was (Author: henning):
[~cstamas] you literally made my point. I did not say anywhere that "highest
version wins". I said that maven works under the assumption that every version
is always backwards compatible to each other.
If you have a dependency A that uses library "1.0.0" and then add that library
to your pom with version "2.0.0", you end up with "2.0.0". And that is
{*}wrong{*}. The build should *fail.* Because there is no guarantee that you
can replace 1.0.0 with 2.0.0.
The other way around is worse: if you have a library that declares a dependency
"1.1.0" and then you use the "1.0.0" dependency, you downgrade a transitive
dependency with a non-compatible version.
This behavior is the sole reason why the dvc plugin exists.
I very much heard the point that this statement is incorrect, but not because
"best wins" but "nearest wins". So let me rephrase that (and I will update the
plugin pages) :
*Apache Maven operates under the assumption that it can replace any dependency
version with any other version based on a "closest to the root wins" algorithm,
that makes it almost impossible to predict which version of a dependency will
end up in the build unless all used dependencies are locked down (e.g. by
adding entries and the resulting build tree is analyzed
to ensure that the different packages end up with versions that are compatible.
Maven has no builtin concept of backward or forward compatible versions, it
assumes that every version can be replaced with any other version based on this
"nearest is best" algorithm and the resulting tree still makes sense.*
Not sure that this makes your life easier or better. Let me know if you can
agree or disagree that this statement reflects reality better.
My *recommendation* would be that we start adopting an actual compatibility
policy (semantic versioning seems to have won) but allow projects to override
that policy (maybe with a new element in the POM; 4.0.0 may be a good
opportunity). But the current behavior is so poorly understood that people are
bound to get it wrong. I got it wrong. :)
> 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: Majo
[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=17813854#comment-17813854
]
Henning Schmiedehausen commented on MNG-7906:
-
[~cstamas] you literally made my point. I did not say anywhere that "highest
version wins". I said that maven works under the assumption that every version
is always backwards compatible to each other.
If you have a dependency A that uses library "1.0.0" and then add that library
to your pom with version "2.0.0", you end up with "2.0.0". And that is
{*}wrong{*}. The build should *fail.* Because there is no guarantee that you
can replace 1.0.0 with 2.0.0.
The other way around is worse: if you have a library that declares a dependency
"1.1.0" and then you use the "1.0.0" dependency, you downgrade a transitive
dependency with a non-compatible version.
This behavior is the sole reason why the dvc plugin exists.
I very much heard the point that this statement is incorrect, but not because
"best wins" but "nearest wins". So let me rephrase that (and I will update the
plugin pages) :
*Apache Maven operates under the assumption that it can replace any dependency
version with any other version based on a "closest to the root wins" algorithm,
that makes it almost impossible to predict which version of a dependency will
end up in the build unless all used dependencies are locked down (e.g. by
adding entries and the resulting build tree is analyzed
to ensure that the different packages end up with versions that are compatible.
Maven has no builtin concept of backward or forward compatible versions, it
assumes that every version can be replaced with any other version based on this
"nearest is best" algorithm and the resulting tree still makes sense.*
Not sure that this makes your life easier or better. Let me know if you can
agree or disagree that this statement reflects reality better.
My *recommendation* would be that we start adopting an actual compatibility
policy (semantic versioning seems to have won) but allow projects to override
that policy (maybe with a new element in the POM; 4.0.0 may be a good
opportunity). But the current behavior is so poorly understood that people are
bound to get it wrong. I got it wrong. :)
> 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] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812532#comment-17812532 ] Henning Schmiedehausen commented on MRESOLVER-391: -- (got pinged from here: [https://github.com/basepom/maven-plugins/issues/9)] These are the use cases that I keep running into: I have a project using depA in compile scope. depA has a transitive dependency on depB. => I expect depA and depB to be on compile, test and runtime path I have a project using depA in compile scope and depB in test scope. depA has a transitive dependency on depB => I expect depA and depB to be on compile, test and runtime path I have a project that has a runtime dependency on depA => I expect depA to be on the runtime path, but not compile or test But now I write a test that needs depA as well. How can I express a dependency in test *AND* runtime scope, but *NOT* compile scope??? Both are very common in my world. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- 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)
[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-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] [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] (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] [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] (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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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-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-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-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-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-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] [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] [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] [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] [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-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] [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] [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] [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] [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] [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] [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] [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] [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] [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-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] [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] [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] [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] [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] [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] [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] [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-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] [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-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] [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-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-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-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] [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-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] [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] [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] [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] [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] [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-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] [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] (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-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] [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] [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] [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] [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] [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] [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] [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.
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] [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] [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] [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-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] (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] (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-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-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] [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] [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-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] [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)
