Hello Henning
Thanks for sharing your experience. I agree that migrating a Maven
project to JPMS can be difficult, and in some cases impossible with
Maven (but possible with Gradle). However I believe that it is a Maven
problem rather than a JPMS issue. JPMS is quite pleasant to use on the
command-line after we understood how it works, especially if we are
willing to reorganize the source code in a Module Source Hierarchy. I
find it simpler and safer than the old way. The main cause of
difficulties is Maven.
Le 2023-09-02 à 01 h 38, Henning Schmiedehausen a écrit :
My current belief is that there is no good path forward for projects
to transition from non-JPMS to JPMS unless you are willing to rework
your maven module structure (e.g. abandon the per-module src/main and
src/test trees, give up test scope)
Regarding JAR files with test scope, I see two solutions to this
problem, but none of them doable with current Maven:
* If the tests are shared between modules of your project but not
outside, and if a source code reorganization is acceptable (with no
visible impact on users), reorganizing the source code as Module
Source Hierarchy can help (it avoids the need for JAR with test
scope). This is what we have done for Apache SIS (more on it below).
* Otherwise I think we need to expand the <dependency> definition in
Maven POM for making possible to instruct Maven that a JAR is
patching another JAR. That information would be used by compiler,
surefire, exec and other plugins for adding --patch-module arguments.
and even then, there are a number of problems in the way various
plugins (biggest offenders are javadoc and surefire) try to "guess"
module path / classpath scenarios
Yes!! This is the most important point that I'm trying to do is my
emails! There is many problems with the way that Maven handles JPMS, but
the most blocking issue and ironically the easiest one to at least
mitigate, is the absence of control on the class-path versus module-path
decisions. This is especially problematic since Maven algorithm for this
decision is partially wrong.
Right now, JPMS feels like a build afterthought that works in very few
extremely specific scenarios and your only choice is to structure your
code exactly in that scenario. I have abandoned the JPMS transition
for Jdbi for now until some of the tooling has improved.
As said before, I believe that the problem is Maven, not JPMS. We
managed to migrate Apache SIS to JPMS, with a lot of efforts but because
of tooling - we could always reproduce easily what we wanted on the
command-line, where we have full control on all options. The SIS project
restructuring, the issues encountered and the workarounds applied are
discussed there:
https://geomatys.github.io/draft/Modularization.html
That migration would have been impossible with Maven, so we had to
switch to Gradle. Even then it was difficult, but it could be made much
easier with more adequate tooling support. Discussions with Gradle
developers about possible improvements started on GitGub issues. On
Maven side we could improve things with small steps. The most urgent one
in my opinion is to give control to developers about class-path versus
module-path decisions.
Martin
