> On Oct 18, 2021, at 1:21 PM, BJ Hargrave <hargrave@xxxxxxxxxx> wrote:
>
> The contents of a Jakarta EE specification project's API jar's module-info file must be specified and is thus standard.
>
> Whether or not we mandate that all Jakarta EE specification projects must specify a module-info for Jakarta EE 10 is somewhat orthogonal. But if they do, then all who provide an API jar for the Jakarta EE specification, whether it is us or it is Apache, etc., must conform to the Jakarta EE specification's definition of the module-info which includes module name, exports, opens, etc. Then all API jars are "plug" compatible with each other in module mode.
>
> This is just like a type in an API. We specify the package name of the type, the name of the type, the members of the type, etc. Any one can provide the type as long as the type conforms to the specification of the type (i.e. signature). A module-info is a type, albeit a special type and it has public signature too.
This is a perspective I can understand. In this case we would need TCK tests to verify the module-info contents to ensue everyone is compliant. We'd also probably would not be able to add that via a service release as there will be new testing requirements.
We discussed this in the last few Jakarta EE calls. The consensus is not to add TCK because Jakarta EE 10 does not reinforce JPMS. What tests will be for? There is little value in having a test to mandate module-info present.
Do we plan to ensure that anyone who provides a module-info in their API jar does so identically to the ones produced by the Jakarta Spec project?
-David
|
