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

["werner.keil@xxxxxxx" <werner.keil@xxxxxxx>]

+1 for Option 1

---

From: config-dev <config-dev-bounces@xxxxxxxxxxx> on behalf of Dmitry Kornilov via config-dev <config-dev@xxxxxxxxxxx>
Sent: Friday, February 21, 2025 7:56 PM
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>; microprofile@xxxxxxxxxxxxxxxx <microprofile@xxxxxxxxxxxxxxxx>
Cc: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
Subject: Re: [config-dev] [External] : Re: Config for Jakarta EE 12 and MP.next

 

+1

---

From: config-dev <config-dev-bounces@xxxxxxxxxxx> on behalf of Ed Burns via config-dev <config-dev@xxxxxxxxxxx>
Sent: Friday, February 21, 2025 19:00
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>; microprofile@xxxxxxxxxxxxxxxx <microprofile@xxxxxxxxxxxxxxxx>
Cc: Ed Burns <Edward.Burns@xxxxxxxxxxxxx>
Subject: [External] : Re: [config-dev] Config for Jakarta EE 12 and MP.next

 

Note about email lists:

As predicted, discussion has fragmented across several lists. I realize this is a side effect of the choice to continue discussion using this "both lists on the To: line" approach rather than introduce another venue.

----------------------------------

Greetings programs​,

After discussion, consideration, and consultation, I continue to believe we need to select the least-bad option for both our communities. The time for selecting an actually good option passed when MicroProfile departed from their nascent goal of MicroProfile being an incubation space for ideas that eventually go into Jakarta EE. For historical perspective, see Ivar's blog post from nearly half a decade ago. To fork, or not to fork | agilejava.eu .

Therefore, Microsoft intends to support option 1: copy the Eclipse MicroProfile Config 3.1 API into Eclipse Jakarta EE as Jakarta Config 1.0. Regarding further development of Jakarta Config: We intend to selectively incorporate sensible changes made in subsequent versions of MicroProfile Config into future versions of Jakarta Config, while retaining the right to develop Jakarta Config in its own right to meet the needs of Jakarta EE.

I will work with Dmitry Kornilov as the project lead for Jakarta Config to go through the specification process. Specifically: create a release plan and go through Plan Review. This approach will allow the Jakarta specification process to proceed with its usual voting.

Let's do a thought experiment to illustrate the untenability of Option 2.

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.

Closing

I realize option 1 does not please everyone, but I trust in the Jakarta specification process to give legitimacy to the result due to the clear outcome of voting on the Plan Review for Jakarta Config 1.0.

Thanks,

Ed

From: config-dev <config-dev-bounces@xxxxxxxxxxx> on behalf of Jared Anderson via config-dev <config-dev@xxxxxxxxxxx>
Date: Tuesday, February 4, 2025 at 10:18
To: config-dev@xxxxxxxxxxx <config-dev@xxxxxxxxxxx>, microprofile@xxxxxxxxxxxxxxxx <microprofile@xxxxxxxxxxxxxxxx>
Cc: Jared Anderson <jhanders@xxxxxxxxxx>
Subject: [EXTERNAL] [config-dev] Config for Jakarta EE 12 and MP.next

You don't often get email from config-dev@xxxxxxxxxxx. Learn why this is important

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

Let's continue discussion using this "both lists on the To: line" approach rather than introduce another venue, such as the cn4j mailing list (eclipse archive).

Sincerely,

Ed Burns and Jared Anderson
Jakarta EE 12 release co-coordinators