I still fail why you need to not respect current maven layout, you are allowed to enhance plugins to be inter maven modules if you want - tycho does it for years - and it would be more natural for maven land IMHO and enables JPMS for the few willing to use this mode, no?
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Le jeu. 15 mai 2025 à 19:23, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2025-05-15 à 19 h 03, Andy Law a écrit : > > > > I don’t understand why this is so different from an aggregated > > project, with ${module} above src, but I may be missing the point > > because I’ve not spent any time thinking about JPMS yet. > > > Because it enables compile-time verification that the compiler can't do > in an aggregated project. Also because it simplifies aggregated Javadoc > for example. On a maybe more minor note, it is also makes the build > faster (compiling 10 modules in a single javac call is faster than > invoking javac 10 times, especially if javac needs to reload many of the > same dependencies each time). > > > > You’re going to give me headaches navigating if you put ${module} > > anywhere below either ${scope} or ${lang} though. Conceptually (to > > me), a module contains scopes and “languages”. > > > Yes, I agree that module contains at least scope. I also admit that not > containing "languages" may cause more problems (in Maven context) than > the problem that it tries to solve. This give us proposal 1: > > src/${module}/${scope}/${lang} > > Martin > >
