Hello fellow Maven & JPMS struggler! I summarized the state of things for Jdbi here: https://github.com/jdbi/jdbi/blob/master/JPMS-SUPPORT.md
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) 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 (and often different within a single maven build). Which is especially sad as JPMS is dependent on "bottom up" transitioning where lower level projects transition first to JPMS and projects "higher up" then follow. For a lot of projects, the "Automatic-Module-Name in manifest" is good enough and the pain to introduce module descriptors is so big that incentive to move forward is limited. Looking at a large project such as Jdbi, we theoretically *can* transition to JPMS (I have a fully working manual build that creates project jars, test jars, executes all the tests and creates javadoc jars), but it seems impossible to get maven to execute the same steps as my collection of scrappy shell scripts. We are discussing more whether silently dropping modules is acceptable user-visible behavior than being pragmatic and creating solutions for users to build fully modularized components. 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. -h On Sat, Aug 26, 2023 at 4:10 AM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Hello all > > MNG-7855 [1] is a quasi-blocker issue (at least a major impediment) for > migration to JPMS. I can try to provide a patch, but I'm not familiar > with Maven internal and would need guidance. Another issue is that > fixing this bug probably requires the addition of a new option, which > would require discussion. > > The bug is in the way that dependencies are dispatched between > class-path and module-path. It is based on the wrong assumption that if > an application is not modularized, then all its dependencies must be on > the class-path. This is not true. An application can be classical > (non-modularized) and still have some or all its dependencies on the > module-path. For the application, it may make no visible difference. > However for the dependency itself, the fact that it was declared on the > class-path or on the module-path can make a big difference. This is > explained in the issue [1] and a "hello-world" project demonstrating > that is at [2]. > > On the Maven discussion mailing list, it has been suggested that the > workaround is easy (duplicate module-info information into > META-INF/services/) and that if a library behaves differently depending > on whether it was specified on the class-path or on the module-path, it > would be a library bug. I question those claims: > > * A module can declare a lot of service providers (~70 in my case), > and being forced to keep module-info and META-INF/services/ in sync > is a risk of inconsistency. > * META-INF/services/ is not always equivalent to module-info. In some > cases, there is no easy way to reproduce the same effect (e.g. > singleton provider instances). > * Reflection methods do not behave in the same way depending on > whether the library was declared on the class-path or module-path. > More generally, the OpenJDK API contains between 100 and 200 > caller-sensitive methods. There is plenty of room for unforeseen > behavioral differences. > * If the library wants to load external JAR files dynamically (after > JVM startup), the ways to do that are totally different: with > URLClassLoader in a class-path world, but with ModuleLayer in a > module-path world. The differences are too large for making > practical to support both. > > So workarounds for MNG-7855 are practical only in simple cases, and > MNG-7855 can become a blocker issue in more complex applications. A > quick and I think "behaviorally correct" fix would be to drop the check > about whether the project is modularized or not, i.e. check only if the > _dependency_ is modularized. This approach was discussed in Gradle as > well [3]. But because this fix may be backward incompatible if some > projects rely on the current behavior, we may need to make this change > an opt-in. So we may need to discuss for a new option. > > A better long-term fix would be to allow developers to specify in their > <dependency> block whether they want the dependency to be on the > class-path or module-path. But that would require a POM model change, so > for now I would like to contribute to a shorter-term fix with a new > option if possible. > > Thanks, > > Martin > > [1]https://issues.apache.org/jira/browse/MNG-7855 > [2]https://github.com/Geomatys/MavenModulepathBug > [3]https://github.com/gradle/gradle/issues/25954 >
