Le 2024-01-03 à 15 h 19, Romain Manni-Bucau a écrit :
I can agree with that so let's move it in a plugin related code maybe?
The call is on core Maven developers. If Tamas (or someone else) moves
everything related to class-path to another location, I will follow. But
I think it would need to be a place shared by all Java plugins.
The SPI registration is different depending you are on the class or
module path.
Yes, but it is different than saying that ServiceLoader does not work
well with modules. Managing those differences is one purpose of better
class-path / module-path control.
So how do I resolve a "library-path" lib which is
org/foo/bar/1.0.0/bar-1.0.0.so for example?
In a custom plugin written by Java code?
* Create a new PathType instance, e.g. named NATIVE_LIBRARIES.
* Create a new Type instance, e.g. named "so", which declares that
dependencies of this type are members of the NATIVE_LIBRARIES paths.
Notes:
o As said before, this requires a minor change in
DependencyProperties API.
o This approach may have changed since December 14th, I'm not sure.
* In the plugin code, call the following:
DependencyResolverResult result =
session.getService(DependencyResolver.class)
.resolve(session, project, ResolutionScope.PROJECT_COMPILE);
List<Path> paths = result.getDispatchedPaths().get(NATIVE_LIBRARIES);
That's all, plugin uses the paths as they want. If there is a need for
custom code specifying what to do when the same dependency belong to 2
or more PathType, it could be done by adding some methods in
DependencyResolverRequest (not shown in above example).
No need to modify it, just run javadoc:aggregate on this example
javadoc:aggregate (as opposed to javadoc:javadoc) is a special case, as
it does not process a single Maven module, but all modules together. So
it needs to compute the union of source-directories, class-paths and
module-paths of all Maven modules, which is indeed not a standard Maven
usage. If I remember right an email seen on this list or on JIRA years
ago, they way that javadoc:aggregate does that is a dirty trick even by
Maven 3 standards. But anyway, 1) plugins will still be allowed to do
dirty tricks if they want, and 2) the need for javadoc:aggregate would
be greatly reduced with Module Source Hierarchy (javadoc:javadoc would
do the same work in a cleaner way), but this is another debate that I
would like to avoid for now.
You said you can declare a type from a pom without coding anything.
Without coding anything in Maven core, i.e., additions of new types are
not blocked by the need to modify and release new versions of core.
Plugins still need their own code.
Martin
