Roberto - “The bottom line for us is that we prefer Jakarta (or any other party) to consume the existing specifications of MicroProfile.”
The tricky thing with that statement arises when you are a vendor that supports both Jakarta EE and MicroProfile in a single product. If MicroProfile architecturally just consumes Jakarta EE then we can handle spec versioning and can track
the latest MicroProfile and the latest Jakarta EE.
If Jakarta EE were to consume MicroProfile specifications within the Platform spec then we are now open to version issues.
For example say Payara version X supports Jakarta EE Y which mandates a spec from MicroProfile Z. MicroProfile releases on a more rapid cadence than Jakarta EE by design so it may become impossible for a product to support both Jakarta
EE Y and MicroProfile Z+1. That is a big change from where the two spec bodies have been since founding.
A similar case arises if the Core Profile of Jakarta EE decided to mandate inclusion of a MicroProfile spec – how does MicroProfile then advance given its dependency on the Core Profile?
Payara from the beginning has tried to support the latest Jakarta EE AND the latest MicroProfile. This could become impossible if Jakarta EE consumes MicroProfile specifications.
From: microprofile-wg <microprofile-wg-bounces@xxxxxxxxxxx>
On Behalf Of Roberto Cortez via microprofile-wg
Sent: 14 December 2022 17:40
To: mike@xxxxxxxxxxx; Microprofile WG discussions <microprofile-wg@xxxxxxxxxxx>
Cc: Roberto Cortez <radcortez@xxxxxxxxx>
Subject: Re: [microprofile-wg] Addressing EE/MP cooperation
Hi Mike,
[a] - No. We believe all current MP specifications have their place, and we are happy to support them in Quarkus and Wildfly.
[b] - No. Our position was always to have MP stand on its own and have interested parties consume it as is.
We agree with the Jakarta / MP Config situation. We preferred to use MP Config as is and adjust it as required for Jakarta.
On the recent discussion about JWT, our position is the same. Consume MP JWT as is and work out the missing pieces as required.
As a Red Hat representative in MP, I have been very vocal about these things on our call, which you also attend, so I hope this makes sense to you. We insisted on defining the rules of engagement between Jakarta
and MP on multiple occasions. Unfortunately, it has yet to happen, and we end up in a situation where things need to be clarified and generate a tremendous amount of discussion.
I totally understand the roles for MicroProfile and Jakarta EE. I respect your position that this is "good practice in specification work," but I strongly feel
the need to make a couple of comments:
[a] You make it sound that the MicroProfile specifications are, for the most part, not "useful" until some criteria has been met.
[b] If I understand everything correctly, Red Hat views MicroProfile as a means to "harvest" specifications when the time is right.
MicroProfile already consumes Jakarta EE specifications (CDI, JSON-P, etc.) that have the history going back to Java EE 7. So why can't the opposite be true??
I didn't understand why there was a need to create a Jakarta Config specification when the MicroProfile Config specification is quite capable of handling configuration
in Jakarta EE applications. We already use it in Jakarta NoSQL. And I won't even get into the proposal to harvest MicroProfile JWT.
I'm a strong advocate for both Jakarta EE and MicroProfile. I serve as a committer to the Jakarta Data and Jakarta NoSQL specifications, and the Garden State
JUG serves on both working groups. I totally agree that we should all learn how to work together. But, it shouldn't come at the cost of one group taking specifications from another.
I look forward to discussing this further in 2023.
We are pulling up this comment we made out of a long conversation on the Jakarta platform dev list for wider visibility.
Red Hat’s view is that Jakarta EE (EE) should focus on maintaining stability and backwards compatibility as the primary usage for us is EE app modernization
via microservices and cloud environment enablement. MicroProfile (MP) features are available for microservice deployment modernization which evolves more rapidly. Once a MicroProfile feature is seen to be useful, integration into an EE architecture that has
been able to upgrade past the EE 9.1/EE10 incompatibilities should not see further arbitrary incompatibilities due to yet more namespace changes. EE should strive to extend MP specifications where possible to avoid unnecessary impact on users of EE and MP,
and simply put, this is a good practice in specification work. The lack of agreement on rules of engagement via the CN4J alliance, along with the discussions around MP JWT leaves us to believe that competition is where the two working groups appear to be heading.
Red Hat is strongly opposed to competing specification based working groups, and until the current competitive stances are resolved and clarified, Red Hat will be reducing activity and sponsorship on all matters other than the resolution of this competition/collaboration
issue.
The respective steering committees need to take this topic up in earnest next year.
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
--
Code,
Test, Write,
Cycle, Run,
Drink, Sleep ...
Repeat
Lead Java Queue Editor, InfoQ
Laissez Les Bon Temps Rouler
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
|
