…path

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.

The first case in which the module info retrieval fails is a JAR
containing a class in the top-level package. This is the originally
reported case in the JIRA ticket MJAVADOC-620.
The FindException has a root cause that says that the usage of
top-level packages is not allowed in modules.

For the test, it is important to build the JAR in a Maven module that
is *not* part of the Reactor. Otherwise, javadoc:aggregate would use
the sources of class Test directly and the bug would not occur.
This has been achieved by *not* adding the test project
maven-MJAVADOC620-jar as a <module> to the main project. Instead,
in invoker.properties, the first project is built using option -f.

Note: The artifactId may not be maven-MJAVADOC-620-jar (with a dash
before the issue number), because then, the module info retrieval
fails for another reason, namely not being able to derive a module
name. This is tested by an upcoming second integration test.

Without the fix, maven-MJAVADOC620-jar-1.0-SNAPSHOT.jar is not added
to the classpath and building the JavaDoc fails, because class Test
is not found.
With the fix, maven-MJAVADOC620-jar-1.0-SNAPSHOT.jar is added
to the classpath and building the JavaDoc succeeds.

The second case in which the module info retrieval fails is a JAR
with a file name that contains a number *not* followed by a dot.
This is the case we experienced, because we often use 1-SNAPSHOT as
the working version, resulting in a JAR file name like
"foo-1-SNAPSHOT.jar".
The FindException has a root cause that says that the module name
derived from the file name, "foo.1.SNAPSHOT", is invalid because "1"
is not a valid Java identifier.

Compared to the first integration test, the version number of the
test project has been changed from "1.0" to just "1".
To test one failure cause at a time, the test class Test has been
moved from the top-level package into package "somepackage".

Without the fix, maven-MJAVADOC620-jar-1-SNAPSHOT.jar is not added
to the classpath and building the JavaDoc fails, because class Test
is not found.
With the fix, maven-MJAVADOC620-jar-1-SNAPSHOT.jar is added
to the classpath and building the JavaDoc succeeds.