Le 2024-01-03 à 12 h 08, Romain Manni-Bucau a écrit :
I would like to see a proof in the form of an "hello world"
application (…snip…)
Yot got some on github.
Can you share the URL?
defaulting on the classpath is fine only if the library developers
applied workarounds (…snip…)
The opposite got proven too
Which opposite do you mean? If it is "defaulting on the module-path",
this is not the proposal. The proposal is: comply to developers
instructions when they are explicit, otherwise check if the dependency
is modularized.
I fail to see why you try to impose a single reduced use case to core.
Because currently, class-path is managed in core. If class-path become
managed in a different place, I will move module-path management in that
place too. No matter where class-path is managed, I think that
module-path and patch-modules need to be managed in the same place,
because module-path is (partially or fully) a replacement for
class-path. And I think that this management needs to be the same for
all standard Java tools, at least by default.
Workarounds are needed both ways but a lib can't, today and likely for
some serious years, enforce people to consume it as a module, just
because most of the runtime environments don't support it well enough
(service loader is a good one here).
Workarounds are needed only if a library needs to be usable on *both*
class-path and module-path. Whether a library developer targets only the
class-path, or only the module-path, or both, is developer's choice. On
Maven side, I believe that our task is only to make all those 3 options
as easy as each other. Nothing more.
I'm not sure to understand correctly the allusion to service loader,
because the sentence seems to said that java.util.ServiceLoader does not
support modules well, which is not true. Or maybe you identified issues
when a service has some implementations on the class-path and some other
implementations on the module-path? Even if it is the case, the proposal
allows developers to force a dependency to be on the class-path. It is
just that if a dependency is forced on the class-path, then *by default*
it will be there for all tools: java, javac, javadoc, etc. But even that
is overrideable.
Just give it a try to write a small lib (a "commons" for ex ;)) and
make it classpath and module friendly using a module aware javadoc and
mainly a classpath build. Now do a lib consuming this first lib with
the same constraint (be consumable by anyone since most of libs desire
that) and you'll see what I mean.
I don't see what you mean. I proved my point with a test case which does
what you said: a small lib (called "service") and a lib consuming it
(called "client"). Can you show your point by modifying this test case,
or create a new one please?
https://github.com/Geomatys/MavenModulepathBug
once again it is used today by being explicit, requires a bit more
work but you can't proove it is not doable
I proved my point with above test case. Please prove me wrong by fixing
above test case without transforming Maven into Ant (i.e. without
declaring module-path in <compilerArgs> or similar option).
Rewind a bit the threads and see that the original topics in that area
were not JPMS - some started before JPMS - but processors, agents to
cite the most known. You still don't solve that since both of them are
obvious path which are not consistent between plugins.
I answered those points in previous emails. The discussion is going in
circles. Lets stop arguing and talk with codes and test cases.
(about --add-opens option) This will work when you control the JVM
options but most libs will desire to avoid that and classpath is one
of the known solutions which works well.
As they wish. The proposal is not blocking the use of class-path.
Why would the exec plugin wants to ignore the module-path by design?
Cause it does not launch a JVM so several options will not be not
available.
See addOpens(…), addReads(…) and addExports(…) in
java.lang.ModuleLayer.Controller. I already use ModuleLayer in my own
code for loading user-specified JAR files (while I admit I didn't tried
addOpens(…) and consort).
Do you have an example to define a custom "resource" type in a pom -
no code? If so this part works for me.
Can you elaborate on your use case? After a "resource" type has been
created, where do you specify how to use the path (which option on which
tools) if there is no code? Is it a Maven 4 goal to allows new plugins
to be created without Java code?
New paths do not need recoding Maven core. Only *choices between two
or more paths* need to be coded, and even that part can be made
plugable in a next version if desired.
Agree but means these types neither needs to be there ;).
See above reply. If class-path management is moved outside core, I will
move module-path management to the same place.
Martin
