Hello Maxim
Le 10/12/2019 à 18:30, Maxim Solodovnik a écrit :
Here is the pom https://github.com/apache/openmeetings/blob/master/pom.xml
The command is `mvn clean install -PallModules,rc -DskipTests=true`
I cloned the project and tested on my machine. Downgrading
maven-javadoc-plugin from 3.1.1 to 3.0.1 (by editing line 42 in the root
pom.xml) seems to fix the problem - no need to exclude Jakarta anymore
neither. I opened one module javadoc in Firefox and it seems fine.
The reason why a tried to downgrade maven-javadoc-plugin is because I
looked at the openmeetings-util/target/apidocs/options file created by
maven-javadoc-plugin:3.1.1 and found options there a bit surprising. It
contained an --module-path option with a very long list of JAR files
(presumably all dependencies), even if many of those files where not
Jigsaw modules at all. By contrast, older maven-javadoc-plugin versions
used the traditional --class-path option. I presume that --module-path
enforces the Jigsaw checks, which include verifying that there is no
package collision, while --class-path continues to have the behavior it
always had (to not check for collision). Using --module-path makes
senses for dependencies that are Jigsaw modules, since the developers of
that dependency have been forced by javac to avoid package collision.
But I find surprising that maven-javadoc-plugin puts everything under
--module-path including dependencies that are known to not be ready yet
for Jigsaw.
Another surprising behavior is that maven-javadoc-plugin:3.1.1 also
created a --patch-module option, "patching" openmeetings-util with
apparently all direct dependencies (i.e. asking Jigsaw to treat all
dependencies as if they were part of the openmeetings-util module
itself). It is not clear to me why maven-javadoc-plugin does that. Maybe
it results from the work done for supporting Maven aggregated javadoc
(https://issues.apache.org/jira/browse/MJAVADOC-449).
Martin
