This is very unnatural in maven, where all the source code usually resides in the src directory for a given project. Typical maven projets has a number of files in the root, a src directory and the target directory which contains all generated files. Starting to use other directories is much more disrupting.
Le ven. 16 mai 2025 à 09:04, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > Well, you can still use a standard maven layout and map 1-1 with the > underlying plugin by configuration. > The most natural way is to do parent/moduleX/src/main/java (and siblings) > and handle the compiler plugin in parent to be jpms specific, no technical > blocker, no maven core change needed. > > Not sure why we would reinvent the wheel when we already support it - in > terms of layout, in terms of plugin we have work to do but nothing crazier > than what you already do so I would just finish the work. > > 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 ven. 16 mai 2025 à 00:57, Martin Desruisseaux < > martin.desruisse...@geomatys.com> a écrit : > > > Le 2025-05-15 à 22 h 02, Andy Law a écrit : > > > > > > I still think that the new folder structure feels “dirty”, and from my > > > current position of ignorance, it also feels like the <module> element > > > under <source> actually creates a problem that didn’t really exist. > > > > > The goal of this JPMS work is to give more control to the developers. We > > try to do that by providing Maven configuration options which are mapped > > to Java compiler options in a more straightforward way. For example, > > Maven 3 was applying heuristic rules for deciding whether to put a JAR > > on the class-path or module-path, and a problem was that Maven 3 > > decision was not always what the developer wanted. Maven 4 is > > straightforward: > > > > * If <type> is "classpath-jar", place on the classpath. > > * If <type> is "module-path", place on the module-path. > > > > The same apply to new new<source> element. > > > > * If there is no <module>, put the directory in the --source-path > > compiler option. > > * If there is a <module>, put the directory in a --module-source-path > > compileroption. > > > > The syntax of the --module-source-path option is as below: > > > > --module-source-path module-name=directory > > > > As you can see, that option takes the module name in argument. The new > > Maven <source> element is not an invention of this proposal. It maps > > directly to Java compiler options in the most straightforward way that I > > can imagine. We had no way to use that option in Maven 3, except a dirty > > way using <args> in plugin configuration and setting <sourceDirectory> > > to a dummy value. > > > > Reference: > > > > > https://docs.oracle.com/en/java/javase/24/docs/specs/man/javac.html#the-module-source-path-option > > > > > > > Can someone please point me towards the discussion behind the > > > introduction of that element so I can understand it better? > > > > > There are the wiki pages on the clone used for making the prototypes > > before to submit the pull requests: > > > > * Maven core: https://github.com/Geomatys/maven/wiki > > * Complier plugin: > > https://github.com/Geomatys/maven-compiler-plugin/wiki > > > > Those pages, if accepted, would move to some Maven documentation site, > > but I'm not sure where. > > > > Martin > > > > > -- ------------------------ Guillaume Nodet
