[ 
https://issues.apache.org/jira/browse/MJAVADOC-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Widdis updated MJAVADOC-736:
-----------------------------------
    Description: 
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.

 

  was:
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.

 


> 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
>
> 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)

Reply via email to