Le 2023-11-02 à 17 h 35, Romain Manni-Bucau a écrit :
Now, do the same example but with app in a classpath centric build
(spring boot, EE, ...) which consumes lib1 as a classpath jar even if
it is a module in its original pom (perfectly valid).
Consuming lib1 on the classpath is *not* perfectly valid. It depends on
the library. For being valid, the library must have applied some
workarounds such as duplicating module-info into META-INF/services. If
the library hasn't applied those workarounds, consuming the library on
the classpath will break it.
The workaround doing duplication in META-INF is not too difficult (but
not always easy neither). However, some other workarounds are more
difficult. For example, loading new JAR files at runtime is done in a
very different way (ClassLoader versus ModuleLayer). A library producer
may choose to not support execution on the classpath anymore, e.g. in
order to avoid maintaining two different JAR loading systems. They may
lost some users, but it is not up to us to decide for them.
Regarding Spring Boot, the idea that a non-JPMS application must have
everything on the classpath is a common misconception. A non-JPMS
application can still have dependencies on the module-path. Some peoples
seem to be doing exactly that with Spring Boot [1]. I also demonstrated
that 4 months ago with a Maven and Gradle project [2] for explaining the
issue with current heuristic rules.
[1]https://stackoverflow.com/questions/74214182/how-to-get-spring-boot-project-work-with-jpms
[2]https://github.com/Geomatys/MavenModulepathBug
You can make one of both cases working but not both with your
proposal. Indeed last one will be broken even if it is the most common
one (so we break maven philosophy - and user interaction IMHO).
I still do not see where is the conflict. Both scenarios should work,
including the last one even if the dependency is put on the module-path
of a classpath-centric environment. 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.
By design there is no way to make it work smoothly at artifact level.
Is this statement based on the idea that a classpath-centric application
would need to move module-path dependencies to the class-path? If yes, I
tried to explain above that this is a misconception (executable proof of
concept provided). If no, can you explain where is the problem, keeping
in mind that a dependency on the module-path is not necessarily a
problem even for a classpath-centric application?
Until JPMS reach 40% of projects I guess we should be able to leave
with it and it avoids to introduce any new concept or mess up what
type is for end users
This is not a fair criterion if Maven is making JPMS adoption so hard
(chicken-and-egg problem). Also, this thread initially started as an
issue about agents. JPMS has been added to this discussion because the
issue is basically the same: controlling the path. Tamas's proposal is
trying to address not only JPMS, but also agent, doclet, taglet,
annotation processor and possibly yet more tools to appear in the
future, at all once with one uniform mechanism.
Martin
