Le 2023-11-02 à 20 h 07, Romain Manni-Bucau a écrit :
as of today libs can't ignore classpath cause it stays the majority of
consumers so it is "as if" in this thread IMHO.
Maven can't ignore classpath. But for artifact producers, it is up to
them to decide. They may target a niche market. Or the library may be
internal to a company. Or it may be a plugin for a JPMS application.
if you take the most common packaging which is the fatjar (agree it is
wrong for JPMS unrelated reason but still) it does not support a
single module.
Indeed, fatjar is problematic for JPMS. But the proposal does not block
users from making fatjar anyway if all JPMS modules are
classpath-compatible with the workarounds that I mentioned in my
previous email. Only if some JPMS dependencies are not
classpath-compatible, the user is blocked from making a fatjar. Whether
the dependency is classpath-compatible or not is up to the library
producer to decide, it is not our role to force them (see above point).
Actually I think that keeping JPMS dependencies on the module-path is
what should be done. If a user is nevertheless facing issues, giving
him control is the whole point of the proposal.
Wait, this is what we have today then so we are good.
No, this is not what we have today. Current Maven behaviour is the
opposite (put JPMS dependencies on the class-path if the consumer is not
JPMS) with no way for the users to specify their needs.
But yes, one of both scenario is broken if you test it cause you
inherit a context whereas you can be consummed in two contexts so one
is always wrong until you redo the work...exactly as today so no gain
there.
I have difficulty to understand. I see no broken scenario if the library
is designed for running on the module-path, and Maven indeed put the
dependency on the module-path even for non-JPMS consumers. So what is
broken exactly? Do the two contexts are "separated JAR files" versus
"fatjar"? If yes, indeed as said above creating a fatjar may or may not
work. But should we block JPMS because of fatjar?
Similarly your statement is right, "a dep on the module-path can be a
problem" is true as well so my opinion is we should respect the user
runtime (if not using jpms then don't set module-path).
We can keep the debate about what should be the default location of a
dependency for later. The key point is that we need user's control.
Currently, users have no control.
Agree about having an uniform solution and this is why I mention that
using type is just about trying to fit the set notion in the current
model but without embracing the design which makes it solving the
issue (assinging a set per "path" need).
Both the Set proposal and the <type> proposal would work. I have not yet
seen an argument against the <type> proposal that I could understand. On
the other side, I see three arguments in favour of <type>:
* It does not introduce new elements in the POM model, it only extends
the use of an existing element.
* It does not force users to care about class-path/module-path
distinction when the default behaviour works for them. By contrast,
the Set approach forces all users to care about that distinction,
even when not necessary.
* It keeps the "dependency set" concept available for business logic,
without forcing users to mix their business logic with
class-path/module-path concerns.
Martin
