You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Daniel Widdis (Jira)" <ji...@apache.org> on 2022/10/17 16:08:00 UTC

[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 ]

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)