Please tell me to take this discussion elsewhere if this is not where it belongs, but I’m fascinated by the different mental models that we all seem to carry and I’m always open to shifting my own model if it is wrong.
How do multi-release and multi-module relate one to another in your mental map (@Martin Desruisseaux<mailto:martin.desruisse...@geomatys.com>). In mine, I would define a module as a single Maven project with multiple version directories all under src/main. 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. I still don’t understand what problem the <module> element is solving under the <source> element, unless you want to try to emulate multi-release to build multiple modules. Is that your target use case? Later, Andy From: Martin Desruisseaux <martin.desruisse...@geomatys.com> Date: Friday, 16 May 2025 at 16:27 To: dev@maven.apache.org <dev@maven.apache.org> Subject: Re: Proposal: new default directory layout for modular project Le 2025-05-16 à 15 h 01, Andy Law a écrit : > > OK. I see the purpose of the <module> tag now. > To elaborate on the purpose of <module>: we could argue that javac should be able to discover this information itself by parsing the module-info file. But a single module can have its source files split in many directories (actually, we enumerate all files to `javac` rather than specifying directories, and those files could be located anywhere), and only one of those directories will have a module-info file. For any additional directories (e.g. as we did before with the `add-source` goal of `build-helper-maven-plugin`), `javac` has no way to guess in which module the files belong if there is no `module-name` argument. This is the reason why the `--module-source-path` compiler option and the `setLocationForModule` method of `javax.tools.StandardJavaFileManager` need a `moduleName` argument, and the value of that argument is taken directly from the `<module>` XML element. An example of case where we split the source code in many directories is multi-releases JAR file. When we combine multi-releases with multi-modules, the `javac` compiler needs to know which module we are patching with code for a different Java release. There is usually no module-info file providing this information in the directories of more recent releases. > Instinctively, I would have applied that at the <project> level and > mapped one project to one module (and built multiple modules as an > aggregation of multiple projects) > In addition to my impression that aggregation is not really natural in Maven, I think that this instinct would be different for Maven users who get used to the new <sources> element. This <module> element is part of a bigger picture including <targetVersion> element (for multi-releases), unification of the way to specify Java files and resources, unification of the way to filter files, native support of sources split in many directories (without the need to use `build-helper-maven-plugin`). If we forget <module> at first and just get used to <sources>, I think that after this point, <module> in <source> appears more natural. Furthermore, technically, trying to hide JPMS behind subproject aggregation would not work, or at least not directly. Users would expect the *.class files of each module to be in the target directory of each subproject, but this is not what `javac` produces. We would have all *.class file in the target directory of the parent project, split in directories having the module name: `target/${module}/**/*.class` where ${module} is the value of the <module> element and is generated by `javac` itself, not by us. Unless the Maven compiler plugin move files around after the compilation, users would not get what they were used too anyway. The Java platform is evolving, and JPMS is part of this evolution. Nobody is forced to adopt it, but those who would like to embrace JPMS fully will need to change some habits anyway. Resisting to that evolution may be more trouble for latter, if some future JPMS features become more and more difficult to support without embracing the JPMS model (only for users who want it). Martin The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
