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

Joakim, I am saying something else. The Jakarta project should think of business features as well and bring new features to the Jakarta EE Cloud Native Enterprise Java and maybe with JPMS.
If you use classpath, the module descriptors should not harm the runtime req.
If you use modulepath, it starts to be interesting...

T

On Thu, Oct 7, 2021 at 5:19 PM Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx> wrote:
On Thu, Oct 7, 2021 at 9: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.

The declaration of module-info in the JAR doesn't prevent this use case, or any other.
You don't even have to use the module-info in a traditional sense, you can operate entirely in class-path mode instead of module-path mode and still have all of the perceived flexibility you desire. (Even using Fat/Uber JARs)

There are containers already using JPMS, even in Jakarta EE 8. (See Jetty 10)
How do they do that you may ask?
They have to fork the various spec/api jars and include the module-info.class to accomplish this.

- Joakim
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top