Re: [config-dev] Config for Jakarta EE 12 and MP.next

On 4 Feb 2025, at 18:18, Jared Anderson via config-dev <[email protected]> wrote:

This email is a follow up to the discussion at the 2025-02-04 Jakarta EE platform call.

In that call, we discussed an approach where Jakarta EE 12 could effectively use MicroProfile Config "as is" with some important non-technical accommodations.

1. The APIs for Jakarta Config would be the MicroProfile Config APIs, but with jakarta namespace. Yes, a copy/paste.

2. The implementation may delegate to the MicroProfile Config implementation.
3. The Spec document would be one-line: see the corresponding MicroProfile config spec document.  May need additional text to talk about the difference in namespace and adding in jakarta-config.properties until a new MP Config version added that to its specification.  See #5 below.
4. The TCK would be a copy/paste of the MicroProfile Config TCK and updating the name space and adding jakarta-config.properties testing
5. Need to introduce a new line in the ConfigSource (MicroProfile Config API)
• “Some configuration sources are known as default configuration sources. These configuration sources are normally available in all automatically-created configurations, and can be manually added to manually-created configurations as well. The default configuration sources are:

• 1. System properties, with an ordinal value of 400
• 2. Environment properties, with an ordinal value of 300
• 3. The /META-INF/jakarta-config.properties resource, with an ordinal value of 200
• 4. The /META-INF/microprofile-config.properties resource, with an ordinal value of 100

On 11 Feb 2025, at 16:15, Reza Rahman via config-dev <[email protected]> wrote:

I plan to bring this up in the Jakarta EE Steering Committee. The technical debate aside, I think there are also process and branding/IP considerations here. For one, it's important to track down what the existing consensus had been in Jakarta EE WG/Jakarta Config with regards to namespace. A sanity check from the perspective of branding/IP is also in order as these are in reality two different working groups.

I agree that the most prudent approach is avoiding needlessly introducing mutual inter-dependencies. Both MicroProfile and Jakarta EE should be able to independently evolve their configuration approaches when needed. Separate namespaces with APIs synced manually/selectively when needed does that well.

On 2/11/2025 11:00 AM, Ed Burns via config-dev wrote:

_______________________________________________
config-dev mailing list
[email protected]
To unsubscribe from this list, visit https://accounts.eclipse.org

> Jakarta EE can depend on MP Config, or a core part of it (without CDI). But I doubt that this is the way to go in reality. MP Config most probably cann't meet the standards of Jakarta EE. Another problem is that MP and EE have different release cycles, and, even if EE depended only on a core MP Config part, releases of MP, MP Config Core, and EE would need to be synchronized. I doubt that the MP would accept that.

On Fri, Feb 21, 2025 at 4:34 PM Reza Rahman via config-dev <[email protected]> wrote:

This is indeed a very important branding, marketing, and strategic consideration. What we observe is that while Jakarta EE adoption and usage is not stellar, MicroProfile adoption and usage fares even worse: https://trends.google.com/trends/explore?date=2016-01-21%202025-02-21&q=Jakarta%20EE,MicroProfile&hl=en. These have been the trends for some time now. It's not surprising when customer express the preferences on this matter to us.

On 2/21/2025 9:54 AM, Werner Keil wrote:

 

From: jakartaee-platform-dev <[email protected]> On Behalf Of Roberto Cortez via jakartaee-platform-dev
Sent: 21 February 2025 17:20
To: Ondro Mihályi <[email protected]>; Jakarta specification discussions <[email protected]>
Cc: Roberto Cortez <[email protected]>; Jakarta Config project developer discussions <[email protected]>; jakartaee-platform developer discussions <[email protected]>
Subject: Re: [jakartaee-platform-dev] [jakarta.ee-spec] [config-dev] Config for Jakarta EE 12 and MP.next

 

I’m sorry Ondro, you are being completely unfair with your observations.

 

We had this exact same discussion 5 years ago. In the now inactive CN4J group, there were two proposals, one to move and the other to keep, which were voted and the one to move won:

 

https://docs.google.com/document/d/1dED5v0KgPtCuRlxif6cI_V_G2nKlDCwz3vZETNBgRzY/edit?tab=t.0#heading=h.hjwqu5e5ptjj

 

https://docs.google.com/document/d/1i4q0MxORDjZ99X_sbczXid4AZnS049bbjITj_IKEnpc/edit?tab=t.0#heading=h.qhay327tmakk

 

https://docs.google.com/document/d/19p59GB2y-lSg8CoXz7YY3IZvcMAHIrefQ9J0vOmjlRM/edit?tab=t.0#heading=h.abk3zx3jla3i

 

The MP community never disrupted or hindered any efforts on a Jakarta Config after that decision. In fact, me and Emily were (with some other folks) the most active members in that group, either in calls, commits, issues, and so on. And we were there in good faith and pushed to move things forward, so threatening actions are not a good way to collaborate. You need to realize that based on previous experience, many of us are way more skeptical about the end results, so you also need to be more patient and educate us to convince us that your proposal is the best one. 

 

On 21 Feb 2025, at 16:53, Ondro Mihályi via jakarta.ee-spec <[email protected]> wrote:

 

Jakarta Core Profile cannot accept anything in MicroProfile repositories, as I argumented, it wouldn’t work. Disputing about things like this is exactly what I mean by hindering. We shouldn’t talk about options that just wouldn’t work, that’s a waste of time and going in circles.

 

Ondro

 

On Fri, 21 Feb 2025 at 17:10, Emily Jiang <[email protected]> wrote:

I might have misunderstood what you meant on Option 1.  I will just say Jakarta Core Profile just includes MP Config core. The repo will stay in MP.

 

 

 

On Fri, Feb 21, 2025 at 4:05 PM Emily Jiang <[email protected]> wrote:

My comments are inline.

 

On Fri, Feb 21, 2025 at 3:55 PM Ondro Mihályi via config-dev <[email protected]> wrote:

Exactly as Reza wrote. Just the latest Jakarta EE 10 is implemented by 9 distinct solutions, out of those at least 4 have full or partial support for MicroProfile. Only 2 solutions plus Quarkus primarily support MicroProfile and have no or only partial support for EE. I think this is in line of the adoption trends Reza wrote about.

 

And now, it seems to me like Jakarta EE wants to evolve and bring Config, but MicroProfile has effectively hindered this initiative for a very long time, instead of helping and supporting Jakarta EE, which is at the core of MicroProfile. I don't see why Jakarta EE should take any consideration about MicroProfile at this stage, after MicroProfile choosing the pull model, and after being slowed down with all these discussion how to align with MicroProfile while MicroProfile doesn't even want to collaborate and align with Jakarta EE.

I am not sure what you meant by saying MicroProfile has hindered this initiative. There was suggestions and I said multiple times at some calls. MicroProfile Config is willing to split up into 2 parts: core; cdi parts.

 

I see only 2 options now:

This is the option I offered to help and contribute. This is so far the best approach.

 

If this discussion continues for too long without a resolution, I will strongly support creating Jakarta Config spec without any regard to MicroProfile, either as a copy of MP Config APIs in jakarta packages, or a completely new API. And I will start contributing to Jakarta Config as a committer, together with some other committers who want to do some work instead of wasting time in discussions. There's no reason why these discussions should slow down Jakarta EE. I don't see these kind of discussions in Microprofile, why should we have them in EE?

 

This is indeed a very important branding, marketing, and strategic consideration. What we observe is that while Jakarta EE adoption and usage is not stellar, MicroProfile adoption and usage fares even worse: https://trends.google.com/trends/explore?date=2016-01-21%202025-02-21&q=Jakarta%20EE,MicroProfile&hl=en. These have been the trends for some time now. It's not surprising when customer express the preferences on this matter to us.

On 2/21/2025 9:54 AM, Werner Keil wrote:

As Steve mentioned, the adoption and true certification of MP is merely a fraction of Jakarta EE.

The most recent MP versions only got certified by one or two products, before that MP 6 had 4 compatible products according to Steve. Jakarta EE lists around 20 product by almost the same number of vendors. Not all may have certified against Jakarta EE 10, but in general the number of compatible implementations is higher. And let's not forget, MP as well as Spring also implements some of Jakarta EE, so that multiplies the usage drastically.

 

Regards,

Werner

 

[email protected] schrieb am Freitag, 21. Februar 2025 um 15:20:54 UTC+1:

Hi,

 

Can you please clarify which standards MicroProfile Config cannot meet? 

 

Also, why is there an assumption that MP Config wouldn’t accept some sort of release alignment? MP projects are free to release anytime they want.

 

Cheers,

Roberto

 

On 21 Feb 2025, at 13:21, Ondro Mihályi <[email protected]> wrote:

 

Hi,

 

Yes, MP decided on the pull model. That means that the decision is solely on Jakarta EE, with the pull model, MicroProfile has decided they don't care about EE.

 

Copying/forking MP Config is not the only option, even with the pull model. Even with this model, Jakarta EE can depend on MP Config, or a core part of it (without CDI). But I doubt that this is the way to go in reality. MP Config most probably cann't meet the standards of Jakarta EE. Another problem is that MP and EE have different release cycles, and, even if EE depended only on a core MP Config part, releases of MP, MP Config Core, and EE would need to be synchronized. I doubt that the MP would accept that.

 

For the arguments above, the only reasonable options I see, are:

Thought experiment: MicroProfile Config Core 3.2 (part of MicroProfile 7.1) is used directly from Jakarta EE 12.

• There exists MicroProfile Config Core 3.2. This contains the non-CDI parts of MicroProfile Config 3.1.

• There exists MicroProfile Config 3.2. This contains the rest of MicroProfile Config 3.1 and still defines integration with a specific version of CDI. Specifically 2.0.

• MicroProfile 7.1 includes MicroProfile Config 3.2.

• Jakarta EE 12 depends MicroProfile Config Core 3.2 (which is a part of MicroProfile 7.1).

Problems with this approach

Functionality problems

A key part of the value of Config is the ability to use it from CDI. But because the CDI part is absent from MicroProfile Config Core 3.2, the Config specific CDI feature set is not available in Jakarta EE 12. This is unacceptable, considering how central CDI is to Jakarta EE and MicroProfile.

Consider this existing problem regarding backward incompatible changes. Let's say an EE 12 Core Profile specification introduces a backward incompatible change that does not work with the corresponding version of that specification in MicroProfile 7.1. Now, all vendors will need to incorporate MicroProfile 7.2 (which resolves this dependency problem) before we can have EE and MicroProfile versions that can be implemented by a vendor in a single product. This existing problem is now made even more difficult because the same thing can happen in reverse in the event MicroProfile Config introduces a backward incompatible change.

We are effectively very closely tying the release cycles of Jakarta EE and MicroProfile. This is untenable.

Governance problems

Because MicroProfile Config Core 3.2 is a foundational part of Jakarta EE 12, and MicroProfile Config Core 3.2 is governed by MicroProfile governance, the independent existence and decision making of Jakarta EE is now impossible. For example if Jakarta EE needs a concrete change to MicroProfile Config, Jakarta EE must compel MicroProfile to accept this change in a timely fashion. This turns what was once a one-way dependency (MicroProfile depending on Jakarta EE for several core specifications) into a two-way dependency. To make matters worse, MicroProfile has adopted the pull model, which means they are not committed or bound to address the needs of Jakarta EE.