Hello
Le 2023-09-03 à 06 h 15, Romain Manni-Bucau a écrit :
The thing is you can't rely on the pom to know if you use a JPMS or
not module cause most libs will not fill that and even if, then you
never know if consumer wants that.
The POM change proposal is not for specifying if a dependency is JPMS or
not. The current Maven algorithm checking the presence of
module-info.class or automatic-name in MANIFEST.MF is sufficient for
that purpose. The proposal is for specifying how a user wants to *use*
the dependency (the second part of the quoted sentence). A user may want
to put a non-JPMS JAR on the module-path and rely on automatic module
name (not encouraged, but sometime there is no better alternative), or
conversely a user may want to put a JPMS JAR on the class-path (rarer
but conceivable, e.g. for doing some tests, as it can be a trick for
replacing services). Or the user simply wants to fix an inadequate Maven
decision, which is my main issue.
So you are stucked by design on being explicit on 200 entries paths
with pom updates or not.
Not necessarily, I'm not proposing to remove the algorithm that makes
those decision automatically. I'm proposing to fix it or make it
configurable, because it currently makes questionable decisions. Only
then, a longer term goal is to make possible to override the decisions
on a case-by-case basis. Only that overriding part would need POM changes.
In short term, the problem with current algorithm is that it is based on
2 criteria:
1. The dependency is modularized.
2. The project using the dependency is itself modularized.
Criterion 2 is the problem and needs to be disabled globally. Since it
would be an incompatible change in Maven behavior, we would need to make
that configurable. But it would be a global configuration (e.g. new
plugin options with default value specified by a property) controlling
the *default* Maven behavior when there is no explicit instruction about
whether to put a specific JAR on the class-path or module-path. In short
term, such global configuration would be sufficient for resolving my
issue. In longer term, I think that we need new explicit XML elements in
<dependency> for overriding the default behavior on a case-by-case basis
(and also for more JPMS-related stuff), but this is less blocking.
Martin
