Le 2024-01-03 à 17 h 15, Romain Manni-Bucau a écrit :
see it as "where classpath is in core comes from the time maven was
only for java libs" (i'd say maven 2 cause I don't know maven 1).
The CLASSPATH_CONSTITUENT property and related isAddedToClasspath()
methods were added in Maven 4. I let you (Maven core developers) choose
where to put those properties/methods. My point is that everywhere there
is non-deprecated class-path, should be module-path too.
From what I understood it uses the getpathtype methods of your PR and
limits the type to CLASSES or MODULE, this is where I'm a bit lost.
This is a limitation of the current version of DependencyProperties,
because it uses boolean flags for specifying whether a dependency should
be on the CLASSES set or the MODULES set. So we are limited by the
predefined set of boolean flags. This is why I proposed to replace them
by a single property giving directly the PathType values. This is a
minor change, but maybe I should add a commit for that change now for
clarity.
A lib consumed both as a class path element or module path element
(most libs) generally compiles using classpath and renders the javadoc
with module
I'm not sure what you mean. Class-path / module-path apply to the
dependencies, not to the module that we are compiling (unless you are
talking about Module Source Hierarchy, but this is another topic). If
you mean that libs generally compile with their dependencies on the
class-path, this is not true if for JPMS module. To prove my point, I
have created yet another test case:
https://github.com/Geomatys/MavenModulepathBug/tree/modularized-client
See instruction in the readme. Can you compile this test case with the
dependency on the class-path, without omitting the module-info in the
compilation?
Today javadoc plugin compensate that by *not* respecting the pom
configuration (it has yet another "guess" algorithm which works not
bad) but your wish is to drop that so all the current functional cases
would be broken or you would have to keep what you don't want in the
plugin
If you are talking about javadoc:aggregate, indeed I would not touch
that part. This particular case lives in its own world. But
javadoc:javadoc would work in the same way as java, javac and all other
standard tools.
Martin
