desruisseaux commented on PR #11549: URL: https://github.com/apache/maven/pull/11549#issuecomment-3654959102
Hello @hboutemy and all. First, there are a few Java 9 concepts that I would like to ensure that they are well known: * Since Java 9, `javac` can compile many modules at once. This is possible when using the so-called [module source hierarchy](https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#directory-hierarchies). * There are some [technical advantages](https://sis.apache.org/release-notes/Modularization.html#advantages) in doing that, and no way I'm aware of to get some of these advantages in the traditional way. * When using module hierarchy, the `javac` output is `<module>/<package>/*.class`. The `<module>` additional level is a standard Java output, not something that we decided on our side. * The above additional `<module>` directory level is understood by other standard Java tools such as `java` and `javadoc`. One notable exception is the `jar` tool, maybe intentionally for forcing a limitation of one module per JAR for smaller download. They are been attempts to explain these aspects on the Maven mailing list, on [a wiki with proof of concept](https://github.com/Geomatys/maven/wiki) and with a [real project experiment using Gradle](https://sis.apache.org/release-notes/Modularization.html). However, I got the feeling that the above is still nebulous to most peoples, and that the best way to advance would be to give to developers a possibility to try easily by themselves. The Maven Compiler Plugin 4.0.0-beta-3 is already capable to compile a project organized with module source hierarchy. Consequently, the output in `target/classes` is multi-module when the project is organized that way (again, because `javac` works that way, not because we made a choice that we are imposing to others). For Java tools such as `java` and `javadoc`, this output can still be consumed as a single output with a single `--module-path target/classes` option. This option understand the `javac` module hierarchy output. Therefore, for these tools, the "1 Maven project = 1 main output" pattern could still apply. But as said above, `jar` is an exception (probably intentional). Now about the questions: > what is the pom of "automatic sub-artifactId Java Module" vs the base artifactId? (…snip…) you expect to use the same consumer pom for automatic artifactIds of Java module JAR, just update the artifactId? and implicitly no build pom? Note that when building a project with Maven 4, we already have a `target/project-local-repo/${groupId}/${artifactId}/${version}` directory with a `….pom` and a `…-consumer.pom` files in it. The consumer POM seems to differ from the source POM in that it has comments removed, the `<scm>` and `<repositories>` sections removed, the `${…}` properties resolved to their values and some reformatting applied. My proposal is to replicate the consumer POM for each JAR with the following changes: * `artifactId` set to the Java module name. * Dependencies filtered to the intersections of the Maven dependencies and the `module-info`: * Java modules enumerated in a `requires` statement are ordinary dependency (`compile` scope). * Java modules enumerated in a `static requires` statement are dependency with the `optional` element set to `true`. * `<build>` and `<profiles>` sections removed. Therefore, the base `artifactId` would not be used except for the build (original) POM. > is there a jar associated to the original artifactId? No when using the module source hierarchy. Reminder: nothing change when using the traditional package hierarchy. > when I read "This is needed by the new Maven JAR Plugin proposal https://github.com/apache/maven-jar-plugin/pull/508.";, I don't get the relationship with using jar vs MavenArchiver: we need to be cautious The new proposed JAR plugin automatically detects when module hierarchy is used, and produces one JAR per module in that case. However, it results in an exception thrown by Maven core if the relaxation proposed in this pull request is not applied. Reminder: again, nothing change when the JAR plugin detects that the traditional package hierarchy was used. The reason why the JAR pull request mixes two tasks in the same pull request is because one of the reasons to migrate to the `jar` tool was to handle multi-release JAR files with the `--release` option in order to address https://github.com/apache/maven-jar-plugin/issues/484 and by experience with the compiler plugin (verified again with the JAR plugin), it is easier to address multi-release and multi-module together than separately. -- 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]
