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

[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. <legacyMode>, 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)