Re: [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12

[Reza Rahman <reza_rahman@xxxxxxxx>]

I am sure Ed and/or Jared will respond with their own thoughts - in the meantime let me share my two cents, including on some of the broader technical intricacies.

First a purely personal opinion independent of Microsoft. These are some of the intricacies of managing two platforms run by two separate working groups that in practice need to co-exist closely. It's the reason some of us espoused the hope that common dependencies and possible sources of colliding resources to manage would only be in one direction with the Jakarta EE Core Profile being keenly mindful of the needs of both MicroProfile as well as the other Jakarta EE Profiles (and hopefully in some distant future other non-Eclipse Foundation platforms that also depend on a stable/high-quality/minimal Core Profile). The hope would have been that platforms such as MicroProfile would deprecate APIs that are effectively standardized onto the shared space of the Core Profile.

Setting aside the above purely personal opinion, if MicroProfile is very averse to supporting both Jakarta Config and MicroProfile Config, I don't think it's too hard to just keep Config out of the Core Profile including the small handful of Jakarta EE APIs there (via spec profiles if needed). The major customer pain point is needing to configure the data/external infrastructure related Jakarta EE technologies using old style embedded XML or Java, which are mostly not in the Core Profile anyway.

On 2/17/2025 11:17 AM, Roberto Cortez via config-dev wrote:

If we have separate namespaces and APIs are synced manually / selectively (and evolve independently), I’m guessing that any Jakarta specification would use its own Jakarta Config, and MicroProfile specifications would use MP Config?

In practice, even if Jakarta Config is not part of the Core, if any Core specification adopts it, it would force Jakarta Config with its own API to the MP platform. Is this correct?

Cheers,

Roberto

On 11 Feb 2025, at 16:15, Reza Rahman via config-dev <config-dev@xxxxxxxxxxx> 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:

Even with approaches that allow for mitigating the circular dependencies, I am strongly predisposed to prefer the repackaging approach that allows the content of MicroProfile config to be accessed by Jakarta specifications using an entirely Jakarta namespace.

Ed

From: 'Emily Jiang' via MicroProfile <microprofile@xxxxxxxxxxxxxxxx>
Date: Monday, February 10, 2025 at 18:20
To: microprofile@xxxxxxxxxxxxxxxx <microprofile@xxxxxxxxxxxxxxxx>
Cc: config-dev@xxxxxxxxxxx <config-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [microprofile] [config-dev] Config for Jakarta EE 12 and MP.next

My responses are inline. We will discuss this issue in more detail at this Tuesday's MP Technical call. Please join if you are interested. The joining details can be found here.

On Fri, Feb 7, 2025 at 10:21 AM 'Roberto Cortez' via MicroProfile <microprofile@xxxxxxxxxxxxxxxx> wrote:

Hi Ed,

Thank you for the response.

1. A technical problem regarding introducing circular dependencies.

Yes, the issue is that MP Config is dependent on CDI. This has been discussed many times, and I believe MP is open to make the necessary adjustments and removing that restriction. In the previous Jakarta Config initiative, that was already a goal. One of the things I’ve been advocating is for MP Config (or any other Config specification), to work standalone without any other dependency. This would allow any Java project to consume it without requiring the use of the platform. As for the CDI, that can be an addendum to the specification or even be integrated into CDI itself.

+1. We can rework MP Config to use the CDI approach by dividing MP Config to MP Config Core and MP Config full, where MP Config Core will just have the spi part while the other part will include CDI. In this way, Jakarta can simply include MP Config Core in the Jakarta Core profile. With this, I think Jakarta can simply include MP Config Core with the need of having Jakarta Config.  With this approach, renaming microprofile-config.properties to application.properties is not mandatory as the package namespace would contain microprofile.

2. A non-technical problem where Jakarta specs may not make

   dependencies on MicroProfile artifacts.

Can we clarify what the problem is exactly? Is this something that can be worked out?

What I’m trying to understand is if we could work on the technical and non-technical issues that prevent Jakarta from adopting MP as is (without copying and renaming packages), and assuming we can have those fixed, would Jakarta be able to use it as a regular dependency?

To my best knowledge, there was no restriction for Jakarta to use MP as long as the MP spec do not depend on Jakarta. If MP Config Core is consumed by Jakarta, there would be no circular dependency. 

 

Cheers,

Roberto

On 6 Feb 2025, at 00:40, 'Ed Burns' via MicroProfile <microprofile@xxxxxxxxxxxxxxxx> wrote:

From: microprofile@xxxxxxxxxxxxxxxx <microprofile@xxxxxxxxxxxxxxxx> on behalf of Reza On Wednesday, February 5, 2025 at 07:58 m.reza.rahman@xxxxxxxxx> RR said:

Date: 

RR> Just using application.properties is a good idea indeed.

RR> I am sure Ed and Jared will respond, but I believe the idea here

RR> is to allow both Jakarta EE and MicroProfile to evolve

RR> independently in accordance with their own needs and also

RR> collaborate when best seen fit.

Indeed, doing that now.

From: 'Roberto Cortez' via MicroProfile <microprofile@xxxxxxxxxxxxxxxx> RC wrote:

RC> A few comments inline. Thank you!

On 4 Feb 2025, at 18:18, Jared Anderson via config-dev <config-dev@xxxxxxxxxxx> JA wrote:

JA> This email is a follow up to the discussion at the 2025-02-04

JA> Jakarta EE platform call.

JA> In that call, we discussed an approach where Jakarta EE 12 could

JA> effectively use MicroProfile Config "as is" with some important

JA> non-technical accommodations.

JA> 1. The APIs for Jakarta Config would be the MicroProfile Config APIs,

JA> but with jakarta namespace. Yes, a copy/paste.

RC> After the initial copy/paste, how would things evolve? 

My intention is that technical evolution would take place in the

MicroProfile Config project. In the event of Jakarta specific

accommodations, we would

1. Cross that bridge when we come to it.

2. Try to come up with solutions that are palatable to both communities, Jakarta 

   EE and MicroProfile.

3. If absolutely necessary, we would define content in MP Config that

   would have the proviso such as "this only takes effect in Jakarta

   EE environments". There is ample precedent for such approaches. See

   what we did with Faces when Validation was present (in EE) vs. not

   present (such as in Tomcat).

RC> Would Jakarta keep the APIs in-sync?

Yes. Every time Jakarta needed a new version, they would pick up a

chosen release of MP config to give the copy/paste treatment to.

RC> What restricts Jakarta from using the API as-is?

As far as I know: 

1. A technical problem regarding introducing circular dependencies.

2. A non-technical problem where Jakarta specs may not make

   dependencies on MicroProfile artifacts.

JA> 2. The implementation may delegate to the MicroProfile Config implementation.

JA> 3. The Spec document would be one-line: see the corresponding

JA> MicroProfile config spec document.  May need additional text to

JA> talk about the difference in namespace and adding in

JA> jakarta-config.properties until a new MP Config version added that

JA> to its specification.  See #5 below.

JA> 4. The TCK would be a copy/paste of the MicroProfile Config TCK

JA> and updating the name space and adding jakarta-config.properties

JA> testing

JA> 5. Need to introduce a new line in the ConfigSource (MicroProfile

JA> Config API) “Some configuration sources are known as default

JA> configuration sources. These configuration sources are normally

JA> available in all automatically-created configurations, and can be

JA> manually added to manually-created configurations as well. The

JA> default configuration sources are:

JA> 1. System properties, with an ordinal value of 400

JA> 2. Environment properties, with an ordinal value of 300

JA> 3. The /META-INF/jakarta-config.properties resource, with an ordinal value of 200

JA> 4. The /META-INF/microprofile-config.properties resource, with an

JA> ordinal value of 100

RC> How about dropping microprofile-config.properties (keep it for

RC> compatibility) and jakarta-config.properties, and use

RC> application.properties? This one is already used by many popular

RC> runtimes like Spring, Quarkus, and Micronaut, to name a few.

Roberto, that's a rad idea. I like it.

Ed

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/LV2PR21MB31341CAF5DD63435FB1FB8F096F62%40LV2PR21MB3134.namprd21.prod.outlook.com.

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/574B291B-4999-4068-9306-0A1A1B9F9666%40yahoo.com.

--

Thanks
Emily

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/CAECq3A-%2BjFdx4gHGky0Aw6-39J1ne1jWvoL%2BSdr87Cb1FHcYpA%40mail.gmail.com.

_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org