Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] [config-dev] Re: [microprofile] Config for Jakarta EE 12 and MP.next
  • From: Jared Anderson <jhanders@xxxxxxxxxx>
  • Date: Thu, 20 Feb 2025 18:28:52 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=us.ibm.com; dmarc=pass action=none header.from=us.ibm.com; dkim=pass header.d=us.ibm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GDNDnrHQtI5DqcZJteQoTS6IbAJI22rAZVAbAN/PtVI=; b=qKcGRPT29n6C282rK0vX43iGdN6V6ZyLFiOhLEOUf9MmZI1NWjJD1axZ+DdV5zcPi8Idi3SycCFlu6Wn0RB0cery7GDy5PutzeSyKpTPae9frQRdZM8DsXg326nCXwzh+kTvR7fBvqSMTz8hWZK106TO4Yris5e1qIPHoQFsezMEd+0ShnWqljRhunSSM4trlfxb9cPcwr/9brKGGTVoIhRNDPb+BwRbOkEt/KYK1ORKlu9i3fEhTJTcWQzKx6G6SCzQLBHK552WWcdTuftSzHRLJHGVGMx0FuJBF+OUrIbGsO3CPybIM6Ki/qqbgOoifWQpVtXi4JfR5M9qJ+4EKg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=J/qJvk5COqC8tKfMWFFtgnqNssbQQDjw3EeLj6Xbk/0fHh9AN8XJcHFXPWE3gzvDTBcJWTjwCv2qAQiitAwyQlM2xP0raOTascmV8WBPA1/Iqo/tUoK232KVo6RzJlerCvenxp3tU9bPDATJDat86wVdM6IzrqcnxOnWUlBrcQezz+CrjTS5wQetOIp+ZXTEf5RP4xgRZchESYkUP3FzBJ5TxPgo1He8B4SE0BLhVMLKc/ECcKLBGfsWVvLM8+l+i8RMAThZ86gmYVk65gDKhCIAmre8etGO+03ztep87TAWcqPDYgQ6nXhxOjxH85yTQcibV/VQ2uwnGhzWXAvPag==
  • Delivered-to: jakarta.ee-spec@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/jakarta.ee-spec/>
  • List-help: <mailto:jakarta.ee-spec-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec>, <mailto:jakarta.ee-spec-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jakarta.ee-spec>, <mailto:jakarta.ee-spec-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AQHbg7zYAW1I/vUbU0W0MILti2jp4rNQfreAgAAEY4A=
  • Thread-topic: [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12 and MP.next


The MP Config community will not make a split of the API into two artifacts until AFTER the Jakarta community has made such a decision to consume it.  The only reason they would make such a change is to accommodate Jakarta consuming the core config API in Jakarta.  When the Jakarta community makes a vote to say we will include MicroProfile Config core API into Jakarta, then they will work on making a new release of MicroProfile Config with the two artifacts to accommodate the new Jakarta dependency.

I hope that explains why you don't see any work to split the MP Config API yet.

Jared Anderson

On Thu, 2025-02-20 at 18:13 +0000, werner.keil--- via config-dev wrote:
Depending on the branches you look at, the earlier copies all still exist. And instead of another copy some of the branches might require nothing more than a merge from MP (if everyone involved was willing to do so) to make them compatible. 
Depending on the branches you look at, the earlier copies all still exist. And instead of another copy some of the branches might require nothing more than a merge from MP (if everyone involved was willing to do so) to make them compatible.

MP Config 3.1 was released almost 2 years ago: https://github.com/microprofile/microprofile-config/releases/tag/3.1
The last activity by Emily in 
Emily-Jiang last year
so there is not much difference in recent activity between Jakarta and MP Config.

I could not see any branch that is younger than one year, so unless Emily or someone else forked it in their own personal repositories, the mentioned "core config" vs. "full config" and making the core one independent of CDI must be mostly conceptual so far, and cannot be seen, e.g. in a feature branch of the mp-config repo yet.

Cheers,
Werner


From: werner.keil@xxxxxxx <werner.keil@xxxxxxx>
Sent: Thursday, February 20, 2025 6:28 PM
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>
Cc: Roberto Cortez <radcortez@xxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; Jakarta EE specifications <jakarta.ee-spec@xxxxxxxxxxx>
Subject: AW: [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12 and MP.next
 
> As for Incompatible Changes, the last one made on purpose was in MicroProfile Config 2.0 (released in Mar 2021), and the main motivation was to add new features 
> (the _expression_ support). The last one was the Jakarta rename (which all Jakarta specs also had to do), so I don’t think this is an issue.

The last incompatible changes mentioned were with MP Config 3.0 supporting Jakarta EE 9.1. As this was the namespace change to Jakarta instead of javax. that seems understandable, but the fact, this is in the spec on a regular basis is a bit worisome, and should only be mentioned, if it really applies. Specs like Jakarta Authentication or Servlet do not mention this at all in their current specs.

> - If MP updates, what will Jakarta do? Copy again? Diverge?
If it was copied/donated, then the next version of MP would simply use the Jakarta API, just like e.g. the support of Jakarta EE 9.1 involved changing consumed packages. Some of the "specs" in MP are merely glue between other specs and APIs like OpenTelemetry, OpenAPI or Jakarta REST, so config might even work on a compatible implementation for the API while other committers would contribute to the API in a different place. This was done twice, I am not sure, what happened the second time, otherwise we would not need to have this discussion.

Cheers,
Werner


From: config-dev <config-dev-bounces@xxxxxxxxxxx> on behalf of Roberto Cortez via config-dev <config-dev@xxxxxxxxxxx>
Sent: Thursday, February 20, 2025 4:25 PM
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>
Cc: Roberto Cortez <radcortez@xxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; Jakarta EE specifications <jakarta.ee-spec@xxxxxxxxxxx>
Subject: Re: [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12 and MP.next
 
Hi,

Copying the API is not a decision that should be made lightly. Before even considering that direction, we must consider:

- If MP updates, what will Jakarta do? Copy again? Diverge?
- User experience by having two identical APIs (at first) in their project.
- Runtimes additional work (more classes to load, more lookups, more RSS, more startup time)

As for Incompatible Changes, the last one made on purpose was in MicroProfile Config 2.0 (released in Mar 2021), and the main motivation was to add new features (the _expression_ support). The last one was the Jakarta rename (which all Jakarta specs also had to do), so I don’t think this is an issue.

Yes, I agree there is a technical issue (which I’ve pointed out many times) about MP Config depending on CDI, but a copy to Jakarta will not fix that. The MP community already expressed willingness to make the necessary adjustments for the spec and the API to be consumed as-is in a standalone way. In reality, it could have been done a long time ago, but previous efforts around a Jakarta Config specification hurt all the outstanding work in MP Config.

Cheers,
Roberto

On 20 Feb 2025, at 11:35, Steve Millidge (Payara) via config-dev <config-dev@xxxxxxxxxxx> wrote:

 
+1 to Werner here for copying the API into the Jakarta namespace within a Jakarta specification as a first step.
--
Steve Millidge

 
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx>On Behalf Of werner.keil--- via jakartaee-platform-dev
Sent: 19 February 2025 20:37
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>
Cc: werner.keil@xxxxxxx; Jakarta EE specifications <jakarta.ee-spec@xxxxxxxxxxx>; Arjan Tijms via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12 and MP.next
 
It was discussed in the Spec Committee call although not much beyond mentioning the two options discussed elsewhere:
·        One approach would be to consume the existing specification
·        Another approach would be to copy it
 
I prefer to copy of the API as mentioned before.
 
Here are some of the most compelling arguments for it:
 
If MP Config was consumed, it would affect how it's developed within the MP release trains and "platform".
 
Config 3.1 https://microprofile.io/specifications/config/3-1/ like all other releases has a chapter "Incompatible Changes".
This is very much a no-go for a stable and mature spec within Jakarta EE, where such incompatible changes happen much slower, than the MP ecosystem and community might be used to.
 
The last incompatible change for Config 3.0 was "align with Jakarta EE 9.1". Which shows another challenge MP Config and all of MicroProfile would face, if it was embedded into Jakarta EE. Config had to predate relevant Jakarta EE releases and be frozen afterwards, while the rest of MP would have to wait for the respective Jakarta EE release before a new release train can depart.
 
The list of MP compatible products: https://microprofile.io/compatible/ has quite a few gaps, e.g. Wildfly 35 seems to also support MP 7, but the last compatibility claim was for Wildfly 27 and MP 5. Some products may even avoid duplicate compatibility and only certify against Jakarta EE, but still support some MP specs at an earlier version. Which could lead to a mix between two or more different versions of MP Config.
 
Best Regards,
Werner
MicroProfile Config provides a way to achieve this goal by aggregating configuration from many different ConfigSources and presents a single merged view to the user. This allows the application to bundle default configuration within the application.
 
 

From: werner.keil@xxxxxxx <werner.keil@xxxxxxx>
Sent: Tuesday, February 18, 2025 9:39 AM
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>
Subject: AW: [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12 and MP.next
 
I also assume, we'll discuss this further in the specification committee.
 
It's not just a namespace issue or circular dependency. If e.g. the Core Profile was to lose config support only to avoid that kind of circular dependency, why can't the API be moved to Jakarta EE and MP use it or act as a compatible implementation?
 
There are also rather different compatibility and quality expectations to Jakarta EE than MicroProfile and if we allow to dilute that, it would affect the platform as a whole and its users.
 
Werner
 

From: config-dev <config-dev-bounces@xxxxxxxxxxx> on behalf of Reza Rahman via config-dev <config-dev@xxxxxxxxxxx>
Sent: Tuesday, February 11, 2025 5:15 PM
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>;microprofile@xxxxxxxxxxxxxxxx <microprofile@xxxxxxxxxxxxxxxx>
Cc: Reza Rahman <reza_rahman@xxxxxxxx>
Subject: Re: [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12 and MP.next
 

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 foundhere.
 
On Fri, Feb 7, 2025 at 10:21AM '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 tomicroprofile+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 tomicroprofile+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 tomicroprofile+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
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
config-dev mailing list
To unsubscribe from this list, visithttps://accounts.eclipse.org

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

Back to the top