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

I believe the first bit of work is to gather context on the decision making/process for MicroProfile/Jakarta Config. My guess is that Oracle/Dmitry and IBM/Emily are the best people to provide that context.

I suspect it is not productive to start over all that again without that context in mind. The end result probably wouldn’t change much given that the ground realities and key players have not changed much. The unnecessary byproduct would probably simply be raising tensions instead of any different outcomes.

It may also be useful to narrow the scope of work a bit to not blow things out of proportion. From a Microsoft standpoint, the only technologies that need to really be sorted out going forward is JWT (and for relatively sound, customer focused reasons). The rest of the MicroProfile technologies are fine where they are in the foreseeable future. Indeed it may even be best to move RPC to MicroProfile (dare I say prisoner exchange? ;-)).

I really hope this helps matters. We also would like to avoid overwrought discussions that just don’t look good from a customer standpoint.
 

From: microprofile-wg <microprofile-wg-bounces@xxxxxxxxxxx> on behalf of Roberto Cortez via microprofile-wg <microprofile-wg@xxxxxxxxxxx>
Sent: Monday, December 19, 2022 2:15 PM
To: Microprofile WG discussions <microprofile-wg@xxxxxxxxxxx>
Cc: Roberto Cortez <radcortez@xxxxxxxxx>
Subject: Re: [microprofile-wg] Addressing EE/MP cooperation
 
Hi,

I appreciate your replies. I want to provide a few comments. Please keep in mind that my intention is not to start yet another heated discussion but to contribute with constructive ideas.

Steve,

I understand the issue. This already happens when any Jakarta specification new APIs and breaking changes. This is not noticeable because individual specifications are usually updated only for the big Jakarta platform release. Some of the MP specs in talks to be used by Jakarta can be considered stable and safely consumed. They would require adjustments for sure, and I believe that the MP community would be extra careful in a scenario where Jakarta consumes such APIs. It is definitely possible if both communities want to work on that path.

Ondro,

Yes, there are problems with cyclic dependencies, but these are workable. The most noticeable one is CDI / MP Config. Even moving Config to Jakarta still maintains a cyclic dependency on CDI. The alternative (as proposed) is to develop a Config system that does not depend on anything so every spec can use it, and that could be done anywhere (both Jakarta or MicroProfile). As developers, we deal with cyclic dependencies all the time. Even if we move MicroProfile as is to Jakarta, it will not solve that issue. It is going to mitigate some of it, but the problem is still going to be there.

Your 3rd proposal optional is very reasonable We proposed it for MicroProfile Config, but it didn’t get enough support, so a new Config API / system is being developed with a completely different API. At some point, we will end up with two Config systems.

Reza,

I also agree that we want to shield users from all this complexity. Unfortunately, we are failing, so we must turn things around quickly. But if everybody else is happy with the current state of things, please let me know, and I’m happy to get out of the way.

All,

I propose we come up with the questions that need to be answered, and once we are happy, we collectively try to find the answers for them. Many of these have been discussed before, but we still need an agreement and a set of rules of engagement between both communities that can be pointed to with the answer when something comes up (like we do with any specification). I’ll start with a few:

- If a MicroProfile Specification moves to Jakarta:
- Does it retain the namespace? Or requires a package rename? And Maven coordinates?
- What happens to WG members that have a vote on MicroProfile, but cannot vote on the moved specification because they are not part of the Jakarta WG?

- Collaboration:
- Where should new ideas/specifications be implemented?

- Single WG:
- Are all the MicroProfile specifications moving to Jakarta?
- What about certifications targeting Core + MicroProfile only?
- How are fees going to be aligned?
- Where should experimental specifications be implemented?

Cheers,
Roberto

On 17 Dec 2022, at 10:17, Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:

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
_______________________________________________
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