Le 2025-05-17 à 18 h 30, Andy Law a écrit :
How do multi-release and multi-module relate one to another
From the user's point of view, they are orthogonal. We can use
multi-releases or not. We can use multi-modules or not. Those two
features are governed by two independent XML elements inside <source>,
namely <targetVersion> and <module> respectively. Under the hood, the
Maven compiler plugin needs to use a different set of compiler options
depending on whether multi-releases is used alone or together with
multi-modules (this is another reason why it is practical to keep those
options under the same <source> element, because the plugin needs those
two information together). But it can be transparent for users.
I would define a module as a single Maven project with multiple
version directories all under src/main.
For a non-modular project doing a multi-releases JAR, yes, it is exactly
that way and is already supported in maven-compiler-plugin 4.0.0-beta-3
(not yet released) with configuration like this example:
https://github.com/Geomatys/maven-compiler-plugin/wiki/User-guide#multi-releases-project
Because one project maps to one module, there is no need for the
compiler “… to know which module we are patching with code for a
different Java release” because it is obviously the only module that
is being generated by the project.
Yes, this is right for non-modular projects. That sentence that I wrote
in my previous email is true only for a project mixing *both*
multi-releases and multi-modules in the same project.
Again, <module> is only for peoples who want JPMS. For peoples who are
not interested in JPMS, all the evolution done in Maven core and in the
compiler plugin have been designed in such a way that users can ignore
JPMS and nevertheless get the other improvements, such as
multi-releases, without any need to care about module.
Martin
