Le 2023-12-19 à 14 h 12, Guillaume Nodet a écrit :
Sure, but you asked for an API, there's none so far.
Right, thanks for the information, it is really useful for putting me on
track.
I'm not sure what kind of API we could offer, as this depends on what
you want to build. If you build an OSGi plugin, you may want to
restrict the visibility to exported packages, kinda like with JPMS.
Takari lifecycle does this sort of thing too. So the API depends on
the packaging / type of artifact you're building imho.
Probably for some packaging. But there is also a common ground. The
algorithm is the same for java, javac, javadoc and jshell tools, just to
name the ones that I remember. So the idea would be to have common
algorithms covering at least the needs of standard JDK tools. I hope
that OSGi could, if they want, pickup the results and apply their own
modifications on it. An API may look like this (draft to be
revised/expanded later):
https://github.com/Geomatys/maven/blob/explicit-module-path/api/maven-api-core/src/main/java/org/apache/maven/api/DependencyPaths.java
Imho, but Tamas has thought about it more afaik, JPMS modules should
have their own packaging / lifecycle, not reusing plain JAR, as the
rules are different. The compiler plugin maybe should be a different
plugin too, that would make things less complicated maybe.
They would have their own packaging, named "modular-jar", but the "jar"
packaging would also apply at least for compatibility with current
behaviour. In Maven 3, "jar" packaging means "autodetect" (the Maven 3
auto-detection algorithm has a problem, but this is another story).
Another argument is that, in the current Java ecosystem, we have a mix
of modular and non-modular dependencies. So we cannot create cleanly
separated plugins. Each plugin needs to be able to handle a mix modular
and non-modular dependencies. Thus the proposal to define a common API
dedicated to dispatching dependencies between different kind of paths,
covering at least the paths defined by standard JDK tools.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
