Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] module-info tests

Will the version information of the module descriptor also be tested?

Currently, in Piranha our API implementation version follows the whole project versioning, like 21.9.0, 21.10.0, so the version
returned by the ModuleDescriptor::version would be Optional[21.10.0], and not Optional[5.0] for the Servlet API in this case.

On Out 7 2021, at 11:58 am, Tibor Digana <tibordigana@xxxxxxxxxx> wrote:
Have you guys ever thought about business benefits from the module descriptor?
If the module descriptors exist, they have to be tested.
Unless we have a business feature with module descriptors in Jakarta EE, it is useless to introduce them in the JAR.
I have a business feature in my mind:

Imagining that you have EE containers in a Cloud. Your application has module descriptors and the application can select the EE stack and versions. Then your microservice would not include the infrastructure JARs because these JARs/modules can be selected via the module descriptor of the application. The trick is that the Fat JAR would not include the infrastructure JARs because they are on the server and the best is that the application can select the version of the API and container. I am calling it software as service on the Cloud, and the s/w service is a list of containers and their vendors.

After we have provided the ability to select the version of the Spec in the application, we would kick off a new strategy of the deployment (small JAR/WAR without embedding container jars in the app) and new services in the Cloud.
It is something between Fat JARs and application servers because your app is really server-less and it is not like an application server but the Cloud vendor would have a container of containers.


Sent from Mailspring
On Wed, Oct 6, 2021 at 10:06 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
It was brought up that some api jars like bean-validation need to be updated to include a module-info.class, but it was unclear what requirements are needed to verify this. TCKs do not run with modules enabled. I just did a basic test of accessing the java.lang.Module information for a class loaded via the class path from a jar with a module-info.class, and of course the class was loaded from the unnamed module.

It seems like the baseline validation of module-info.class for api jars will have to be some check for existence as part of the specification pull request review. This is something that can be added to the existing automation work.

If other projects want to add additional TCK tests, I suppose they could, but since it is not a requirement for implementations to run with modules enabled, it probably won't work. For the next platform call we need to clarify exactly what module-info.class validation is required, and whether projects like bean-validation can simply put out a service release that includes only the api jar, no TCK and obviously no spec updates.

jakartaee-platform-dev mailing list
jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top