commit e4efc0f184a75f852975a8c3318960b3f9391204
author fwienber <frank.wienberg@coremedia.com> Mon Nov 18 17:41:13 2019 +0100
committer fwienber <frank.wienberg@coremedia.com> Tue Nov 19 13:42:54 2019 +0100
tree fc5746a905b9c40bcdbdb6f55b2b6ec620ebb8ac
parent b1b28fe72ec89d42856f4c046421076169073946

[MJAVADOC-620] Do not ignore JARs w/o module info when building classpath

When locationManager.resolvePaths() processes JARs that do not define a
module name, module-name-guessing is triggered. The last resort is to
use the JAR's file name to derive a module name. The heuristic is to
determine where a version number starts, for which the regex
is used: "-(\\d+(\\.|$))"
See https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/module/ModuleFinder.html#of(java.nio.file.Path...)

For the remaining prefix, all non-alphanumeric characters (this
includes dashes) are replaced by dots. When splitting at the dots,
every part must be a legal Java identifier.

Now, when a Maven JAR uses the version "1-SNAPSHOT", the JAR is named
<artifactId>-1-SNAPSHOT.jar, so the version suffix is not recognized by
the heuristic (the number is neither followed by a dot, nor is this the
end of the file name without extension), so trying to guess the module
name eventually fails with an error (FindException, "1" is not a valid
Java identifier).

There are other situations in which trying to derive module information
from a JAR leads to errors, e.g. when the top-level package is
used ("unnamed package not allowed in module").

The code in maven-javadoc-plugin checks all returned classpath elements
whether they contain module information. Now, in the result returned by
locationManager.resolvePaths(), all JARs for that no module information
could be derived are not contained in getClasspathElements(), but only
in getPathExceptions(). When a JAR path is mapped to a FindException,
it does not make sense to look for module information, but it *does*
make sense to still add these JARs to the classpath.
Ignoring them, as before, is what breaks backwards-compatibility with
non-module JARs and causes bug MJAVADOC-620.
The fix is to add all such JARs without module information to the
JavaDoc classpath.