Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit :
putting a dependency on the module-path of a non-JPMS application
such as Spring is okay
Is not ok for me and is a big hidden bug of current guess logic when
not disabled IMHO, we should drop all that guess code probably.
The current guess code in Maven 3 puts the dependency on the class-path,
which in my understanding is the behaviour that you want. The <type>
proposal would put the dependency on whatever path the <type> said it
should be. If the user is not okay with that, (s)he can override in the
same way that (s)he can override the version of transitive dependencies.
A dependency may be designed for working only on the module path (it is
developer's choice as any other software requirement, such as the
minimal Java version), which is why I think that by default, dependency
should go where the library producer said that it should go. But again,
users can override if they want.
Then question is how do you enable modules but this is not a question
for your maven module but per plugin (jaxws plugin will not use the
same modules than compiler nor javadoc for ex). This is where the type
proposal is not granular enough to handle advanced cases we are
talking about
Are you referring to the --add-modules or --limit-modules options of
Java? If so, I think that they are compatible with the <type> proposal
and can be discussed in a next step. The first step that we are trying
to resolve now is to build the module-path. Next, it is indeed possible
to tell Java to "see" only a subset of the modules available on the
module-path. I think that this option is more typically used when the
module-path is a whole directory instead than an enumeration of
dependencies as Maven does. If users nevertheless want to use the
--add-modules or --limit-modules options, maybe they could be options of
the exec plugin. Those options are not paths, only comma-separated lists
of modules names.
(…snip…) ie put all the code in src/main cause by design it is what
you want, a single module where maven creates 2 modules per maven module
I'm not sure if you are talking about the Java compiler's "Module Source
Hierarchy" here. If yes, this is indeed something that I would like, but
I'm not trying to push that for Maven (I presume that it would be a too
big change). My hope for Maven has smaller scope: module-path and making
easier to setup the --add-exports and --add-opens options.
Not sure I understand the issue, you highlight a bug in exec maven
plugin (classpath and module path configuration share a single toggle
- and toString BTW) but ultimately you misconfigured the plugin too:
Thanks for the configuration tip, but it works by setting the
--class-path and --module-path options in the <arguments> block of the
exec-maven-plugin. My issue was also execution with surefire, javadoc,
etc. All plugins need the same configuration.
it is really about getting split paths more easily than getting a
global for the maven module configuration which will prevent you to
configure accurately each plugin which is actually required for these
advanced JPMS cases (jaxws is really a hurting case).
Global configuration is also desirable. Per-plugin tuning may also be
desirable, but there is good chances that they would be modifications of
the global configuration instead of something independent (providing
that the global configuration has the <type> proposal).
Agree, default should stay classpath and module path shouldn't be
enabled until requested, creates too much weird behaviors IMHO.
Weird behaviour happens when the library is not on the path it was
designed for. Weird behaviour if we put a designed-for-class-path
dependency on the module-path, and potentially broken behaviour if we
put a designed-for-module-path dependency on the class-path. The reason
why we do not observe the latter often is because library producers are
aware that the Java world is still a lot class-path centric, and
provides workaround in their library for making execution on class-path
possible.
Martin
