Le 2023-12-19 à 15 h 30, Romain Manni-Bucau a écrit :
Side note: the api is similar for the plugins you mentionned but it is
not the same since you can want to compile with everything on the
classpath, (…snip…)
Some developers may want to put everything on the class-path at
compile-time, other may want to use module-path. This is why the
"modular-jar" / "classpath-jar" type proposal aims to give control to
developers. On my side, I use module-path.
(…snip…) so any plugin is really isolated from others (…snip…)
I don't think it is the case. We want to let developers control their
class-path / module-path configuration. But no matter what the
developers choose, I think that all plugins (at least the ones for
standard JDK tools) should apply the same configuration by default.
Otherwise, surprising behaviour will occur. For example, if the
developer puts everything on the classpath at compile time, but uses
module-path at runtime, then the compiler may not report that some codes
are trying to access non-exported packages (because this encapsulation
is enforced only in modular projects), while the JVM may throw runtime
exceptions or linkage errors if that encapsulation become enforced at
runtime.
So I argue that we really want the same "class-path versus module-path"
dispatching for all plugins by default, at least as a starting point.
Plugins may ignore some paths (e.g. doclet-path makes no sense for
javac), or add their owns, or amend some paths, but it can be
modifications on top of the common base. So my proposal is:
* Allow developers to specify "modular-jar" / "classpath-jar"
packaging for each dependency if they want (it would be optional).
* Honour developer's wish consistently, in the same way, for all
plugins expecting those kinds of paths. This is why I think a
dedicated API for this task is desirable.
* Plugins can ignore that common API and derive the paths themselves
from the dependencies if they wish.
which enforces, as we mentionned in the original thread, each plugin
to have a set of dependency set identifiers to work (type in this PoC
but hopefully we can find something else more user friendly later). So
for me the common api is depService.findDependencies(dependencySetIds)
but nothing more. Defaults can overlap then to make it backward
compatible and smooth by default but don't think we should look for
anything else which will likely block users more than helping (as
current "guess" algorithm which enforces explicit configuration for it
to work).
The proposal would not be a guess algorithm, except for the "jar" type
if we keep something like Maven 3 auto-detection algorithm. We have two
kinds of things specified by the users:
* The artifact type ("modular-jar", etc.).
* The scope (runtime, compile, etc.)
Determining paths require combining those two information. The process
is deterministic for "modular-jar" and "classpath-jar" types. But in any
case, it would not block users. Plugins would not be forced to use the
proposed API. They could ignore it and handle dependencies themselves if
they want.
Martin
