|Re: [jakartaee-platform-dev] JPMS requirements discussion|
About the exact phrase of „reliance on automatic module name is not allowed“ I guess that means every module even those that have defined at least an „automatic-module-name“ in the MANIFEST must convert to a „module-info“ or should it say something like „spec provides explixit JPMS module Definition“ (see https://dzone.com/articles/explicitly-naming-automatic-java-modules) ?
If EE 10 is not willing to declare a platform Level module yet I guess that is acceptable for some time, but sooner instead of later we should also offer something like „java.se“ in the JDK (https://docs.oracle.com/en/java/javase/16/docs/api/java.se/module-summary.html) preferably in JARs like https://search.maven.org/artifact/jakarta.platform/jakarta.jakartaee-api or https://search.maven.org/artifact/jakarta.platform/jakarta.jakartaee-web-api.
Adding these in 10.1 or beyond sounds doable, if the pressure on implementors to use JPMS really should be lowered that way, but IMO if you don’t adopt JPMS in your application by not putting a module-info there, it would not create harm or pressure on those apps, and it would create sanity and consistency if done in the official JARs.
We see what happens otherwise with MicroProfile which has ignored and refused JPMS anywhere in ist API.
So some projects like Helidon do this on their own, see https://github.com/oracle/helidon/blob/master/config/config-mp/src/main/java/module-info.java, with an „assumed“ module Name for MP-Config of "microprofile.config.api", but nobody can predict or prevent MP from using a different namespace like "org.eclipse.microprofile.config" which would match the artifactId and package like Helidon itself does.
So it creates a Proliferation and Fragmentation and even adds a bit of Vendor-dependency with those modules Jakarta EE tries to avoid, hence it would be better to define those in the Jakarta Platform API JARs as soon as everyone was happy to do so.
Especially for the Core Profile why introduce that and not start with a module definition right from the beginning?
This topic was discussed on the Platform Call today. The following suggestion was the result of this discussion. Please comment here on the thread, and maybe we can reach a decision on the call next week.
o Suggestion for EE 10
§ Each individual spec provides a module info following a specified set of conventions:
· spec module name is jakarta.<specName>
· spec provides JPMS module definition (reliance on automatic module name is not allowed)
· spec updates provider lookup algorithm to include search on module-path (if applicable)
§ We will not provide a platform/profile level module for EE 10
· Don’t want to set the expectation that implementations must support JPMS at this point
· Implementations can still experiment with their own aggregator modules
On Wed, Jun 9, 2021 at 12:48 AM Jason Greene <jason.greene@xxxxxxxxxx> wrote:
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.
Back to the top