desruisseaux commented on PR #11549: URL: https://github.com/apache/maven/pull/11549#issuecomment-3657917487
> Saying that, is "multi-module JARs" a good description? each jar is a single module, but it is a multi-Java module build done (with one single compiler invocation), isn't it? Correct, each JAR is a single module, and the multi-module build is produced by one single invocation of the compiler. I agree that "multi-module JARs" may be confusing. "Module hierarchy" when talking about the directory layout, or just "multi-module" otherwise, would probably be safer. > one question: one reason for having one build pom per sub-project is that there are resources, assemblies, and everything that goes beyond just the compiler step, and also there are unit tests, and ITs, and everything else Resources are supported by the new `<source>` element. For JUnit tests, a command like `java --module-path target/classes` accepts the module hierarchy as a whole, so it will still like a single output from Maven Surefire point of view. For assembly, if we are talking about things like "fat jar", they are not compatible with Java modules as far as I know because I don't see how we could merge all the `module-info` in a single one without altering the semantic. > I'm still not convinced <source> can replace what we configure with plugins in a sub-project Indeed, `<source>` does not replace everything. It replaces `<sourceDirectory>`, `<testSourceDirectory>`, `<resources>`, `<testResources>` and `<scriptSourceDirectory>`. Other plugin configurations stay in the plugin (except the ones for specifying some kinds of dependencies such as processors, but this is another topic not related to Java modules). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
