The issue is that if JPMS is not included, you get nasty warnings such as:[WARN] *****************************************************************************************************************************************************************************************************
[WARN] * Required filename-based automodules detected: [microprofile-config-api-3.0.2.jar]. Please don't publish this project to a public artifact repository! *
[WARN] *****************************************************************************************************************************************************************************************************
Since Java 9+, all of JDK is JPMS-modularizied, there is no downside to included module-info in Jakarta EE spec JARs, thus the requirement in the SPEC, which is great and should definitely be there.
Why would the module info make anything less stable?
Itd presence impacts your deliverables and app linking in most tools. If not specified and in the spec then it makes your app unstable compared to not delivering it and staying in unamed module.
If specified EE should support jpms.
Side note: same applies to osgi meta.
If your app does not declare one you don't need to bother, but it makes usage of the official Jakarta EE APIs as opposed to internal or vendor specific packages much better to control. Had a proper JPMS be available sooner, the whole " sun.misc.unsafe" and other problems could have been avoided much sooner. -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Hi,
Technically if JPMS is a vendor responsability it would be neat to say JPMS must not be in jars cause it impacts the way apps are developped if used and if unstable it will impact end users negatively - it is not like maven coordinates which are transparent to code.
As long as we're all on the same page about that, great. Note on that front, we need to avoid saying in specifications that these are features of the spec:
Any spec that refers to the Maven coordinates, module-infos, etc as a feature of the spec should be removed. Spec jars are the responsibility of the implementation and we should avoid referring to one set of them as the one-true version and we should avoid referring to their non-portable features as features of the spec.
We should remove that section of the CDI spec and replace it with language like we added to the EE 10 spec.
--
David Blevins
The requirements are the same as EE 10 in that one should be provided with the indicated naming pattern. The content is unspecified and there are no TCK tests for modules is the status quo for EE 11.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
