Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [microprofile-wg] Addressing EE/MP cooperation

Using Micorprofile specifications in Jakarta EE was suggested and discussed many times and the outcome was always that it's not possible. And for multiple valid reasons. One is the problem with cyclic dependencies as Steve suggested. Another problem is that MicroProfile moves faster and sometimes breaks things, which isn't compatible with Jakarta EE goals. Even the Red Hat's view cited by Scott Stark in the beginning of this thread confirms that "Jakarta EE should focus on maintaining stability and backwards compatibility", so I don't understand that Red Hat in the same statement suggests that Jakarta EE should build on top of MicroProfile.

What I think is possible and could be a good compromise, is that a specification is completely moved to Jakarta EE as is, with only minor modifications, which ideally don't break the API. It would mean that such specifications would retain the org.eclipse.microprofile prefix. A lot of people don't like this idea but I think we need to find a compromise to prevent fragmentation and disputes, and such a compromise looks viable to me.

Then we would have 3 kinds of specifications:
* purely MicroProfile specifications, build on top of EE
* purely Jakarta EE specifications, built within Jakarta EE, can be consumed by MicroProfile (e.g. specs in the Core Profile)
* Jakarta EE specifications which originated as MicroProfile specifications, with org.eclipse.microprofle prefix. These would retain as much backwards compatibility with their latest MicroProfile version but adopt the goals of Jakarta EE like stability and backwards compatibility.

In the case of Config, I can imagine that it would be the 3rd case. However we need to consider the impact on Jakarta EE, because config is an essential feature and it might be confusing if the API doesn't use the jakarta prefix.

In the case of JWT, I think it makes a lot of sense to create a light profile for Jakarta Security that doesn't depend on Servlet, integrate JWT into this light profile, and keep the org.eclipse.microprofile prefix for it. The full profile of Jakarta Security could integrate JWT even further where it makes sense.



All the best,
Ondro Mihalyi

Director, Jakarta EE expert
OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

On Fri, Dec 16, 2022 at 6:49 PM reza_rahman@xxxxxxxxx <reza_rahman@xxxxxxxxx> wrote:
This was indeed one of the key considerations outlined well by Emily, et al during the MicroProfile/Jakarta Configuration alignment discussion: https://reza-rahman.me/2021/04/10/jakarta-ee-microprofile-alignment-survey-results/.

While Microsoft does not directly ship either MicroProfile or Jakarta EE, this is a key concern in terms of the need to explain the inter-dependencies between the technologies to our typically conservative corporate customer base that desires simplicity, stability, clarity and consistency. The current one-way dependency simply adds much less confusion to an already confusing situation.


From: microprofile-wg <microprofile-wg-bounces@eclipseorg> on behalf of Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Sent: Friday, December 16, 2022 12:24 PM
To: Microprofile WG discussions <microprofile-wg@xxxxxxxxxxx>; mike@xxxxxxxxxxx <mike@xxxxxxxxxxx>
Subject: Re: [microprofile-wg] Addressing EE/MP cooperation
 

 

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.

 

 

Steve Millidge 

 

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,

 

To clarify:

 

[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.

 

 

Cheers,

Roberto



On 14 Dec 2022, at 16:56, Michael Redlich <mpredli@xxxxxxxxx> wrote:

 

Hi Scott:

 

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.

 

Mike.

 

 

On Wed, Dec 14, 2022 at 11:25 AM Scott Stark <starksm64@xxxxxxxxx> wrote:

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, TestWrite, Cycle, Run, Drink, Sleep ... Repeat

Director, Garden State JUG

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

 

_______________________________________________
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

Back to the top