Hello Piotr Le 2025-04-01 à 08 h 20, Piotr P. Karwasz a écrit :
I fail to understand, however, the purpose of the "modular project" layout.
All modules are compiled in one single calls to `javac`. It is not one call of `javac` per module. The benefit is that forward references to dependent modules (the opposite of references to dependencies) are resolved by the compiler. Such forward references appear in at least 2 places: Javadoc @see, @link and @linkplain tags, and qualified exports and opens statements in module-info. The modular layout allows the compiler to verify those references and emit warnings or errors if they are wrong. There is no way (as far as I know) to get this safety without "modular project" layout.
This is an opt-in feature: if a developer doesn't want it, nothing force it to use it. But those who want this safety as no way (as far as I know) to get it without such layout.
As far as I know, there is currently no support for multiple JPMS modules in the same JAR.
True, which is why the wiki page said that the "one to one" relationship between Java modules and Maven artifacts is preserved. It would require the maven-jar-plugin to generate one JAR per Maven module. I already have a working prototype on Gradle. The POM is generated for each artifact by taking the dependencies declared in the user POM, and omitting the dependencies that are not declared in the module-info of each Java module. The artifact ID needs to be specified by the user in plugin configuration.
That said, while there is no mutli-modules JAR files at this time, discussions that I have see from times to times on OpenJDK mailing lists give me the impression that such format may appear in the future.
I am also afraid that such a structure will really break IDEs: Eclipse already breaks if there is a separate module descriptor for tests, putting multiple JPMS modules in the same Maven Project will probably also break IDEA.
Yes, it would require changes in IDEs. But the https://github.com/nipafx/module-tooling/ project has been started for discussing the problem of module support in tooling. The discussion includes developers from Oracle, IDEA, Eclipse, Gradle and Maven. The topic of modular project layout has been one discussion among others and I have not see resistance so far. The Eclipse developer already took some action in anticipation for that (improved support of the --module-source-path in Eclipse compiler) as a result of this discussion.
When it comes to JPMS and the current Maven Compiler Plugin, what I mostly miss it the possibility to have two source and output folders for tests: unit/whitebox tests need to break encapsulation and either run on the classpath or with `--patch-module`, while integration/blackbox tests should run from a separate JPMS module.
I can volunteer for implementing that. We currently have "test" which is interpreted as whitebox testing. We need to have the community to agree on a new scope for blackbox testing and add it to Maven Core. It would need to be added to `ProjectScope`, and I guess probably `DependencyScope` as well. After such scope has been added to the core, I can implement blackbox testing in the compiler plugin.
Martin --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
