Daniel Widdis created MJAVADOC-736:
--------------------------------------
Summary: 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
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.
# 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)
