>>
As the package rename is clearly a Major and Breaking Change I’m not so sure if a 8.1 release would do that justice.
I understood this. Let's switch the talk to the major version 9.0.
As it seems we like the idea with released minor versions
(developed in SCM branches), e.g. 9.1, 9.2, and 10.5.
Well, truly, changing the packages are the must, but not enough for me as a user.
I guess the EE Container/API as a Service would be really the Cloud for EE software.
The implementation in Cloud would be Multi-Release JAR with every single API independent.
Example with the webapp module-info.java:
module webapp @ 1.0 {
requires CDI @ >= 3.0
requires JAXRS @ >= 2.2
}
This way I would be able to combine old API_1 from Jakarta 9 but the new API_2 from Jakarta 10 in my WAR file. Theoretically it should be possible.
I think the Spring does not have this and never will have it. Our philosophy is rather different from Spring because we can effectively remove the redundancy from the WAR in the way that the API implementations would stay on the Cloud. The WAR would become pretty small then, platform independent and many platforms capable.
This is my vision of the Cloud for Jakarta EE API.
What is your plan to come with new ideas for the Cloud solution in the market?
I don't mean the container implementations rather than the APIs for the Cloud.
IMHO adopting the MicroProfile into Jakarta EE would decrease the speed of the release of MP. Not sure if it is a great idea to adopt it due to having the Native Cloud bigbang.
The MP as an extension of Jakarta EE would be good and natural extension of EE API if the MP project stays isolated.
That's my opinion.