Le vendredi 05 novembre 2021 à 09:27 +0100, Romain Manni-Bucau a écrit : > Think JPMS is not different from OSGi in terms of requirement (it is > more > broken than OSGi and less used only) so not sure why it would pollute > the > pom, plus depending how you setup your project you don't use the same > thing > so it would hurt maven convention phylosophy IMHO. > So it is good to stick to plugins for JPMS IMHO.
I agree that JPMS is not perfect, but, unless you propose that Maven should rather embrace openly OSGi, the comparison between these two is irrelevant. I propose to help users switch to JPMS, and most of those are not already using OSGi, and will not. (If they are, fine; JPMS and are compatible.) JPMS does represent a significant step forward, for the vast majority of developers not already using OSGi, that lets the Java ecosystem know something more about the dependency graph, and other improvements (see e.g. the book of Nicolai Parlog, https://www.manning.com/books/the-java-module-system). I do not think there is any value in you and I debating here over which of OSGi or JPMS is “better in general”. This question is meaningless. This discussion happened many times already, and leads to no consensus. Multiple pieces of opinion about it can be found easily, some mentioning the superiority of OSGi in terms of how large it embraces (https://www.infoq.com/articles/java9-osgi-future-modularity/), some highlighting that OSGi has much broader goals and therefore also higher complexity than JPMS (https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f). Let’s please try to overcome this lack of consensus and find a way forward for Java. JPMS would be much more used if proper tooling was easily available. Hence, my proposal under discussion here. It is no proper reply to refuse this proposal under pretext that JPMS is not widely used. This is a chicken-and-egg problem. The requirements I listed seem to me like a pretty natural and minimal list of things that an average developer would want to have in order to switch to JPMS. (Also considering the usual “tradegy of the commons” problem that I benefit from _other_ modules being JPMS-ized but not much from JPMS-ing mine in a world where the other ones are not yet.) Before this requirement list is effectively supported by tools that developers are used to (or close variants thereof), it is no strong surprise that the average developer does not delve into the effort of describing their modules formally for the ecosystem to benefit. For example, although I am enthousiastic about the possibilities and future offered by JPMS, I didn’t switch my projects to JPMS either, because I was waiting for proper tooling to emerge. Maven has an important role to play here. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
