Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [config-dev] Config for Jakarta EE 12 and MP.next
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 <emijiang6@xxxxxxxxxxxxxx> wrote:
My comments are inline.

On Fri, Feb 21, 2025 at 3:55 PM Ondro Mihályi via config-dev <config-dev@xxxxxxxxxxx> 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:
  1. MicroProfile will cooperate and agree to move MP Config or at least its non-CDI part to Jakarta Core Profile, and then we can keep the packages without breaking the API
This is the option I offered to help and contribute. This is so far the best approach.
  1. Jakarta Config will be created in Jakarta Core Profile, with jakarta packages, and MicroProfile will need to cope with it. The new API can map the MP Config API or create a variant inspired by it

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?

Ondro

On Fri, Feb 21, 2025 at 4:34 PM Reza Rahman via config-dev <config-dev@xxxxxxxxxxx> 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:
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

radc...@xxxxxxxxx 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 <mih...@xxxxxxxxxxx> 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:
  1. MP Config participates in this process and splits to core part and CDI part, so that the core part can be moved to Jakarta EE Core Profile without package changes
  2. Jakarta EE copies the core part of MP config under the jakarta package prefix and adds it to the Core Profile. Jakarta EE can introduce a new CDI Config integration spec, or the existing CDI spec can specify integration in the non-lite part, which is not part of EE Core Profile. This could still cause conflicts for implementations that provide both MP and EE, but we can hardly do anything about it
  3. Jakarta EE will not care about MP Config and will introduce its own API. This option makes sense only if all other options fail. We tried that already and haven't delivered in more than 2 years.
This basically boils down to extracting core parts of MP Config, and the question is whether to keep the package names or introduce jakarta package names, and whether MP helps and splits the MP Config spec or not. The third option is probably the least desired right now.

Are any other options on the table?

Ondro

On Fri, Feb 21, 2025 at 1:15 PM Steve Millidge (Payara) via config-dev <confi...@xxxxxxxxxxx> wrote:
To be honest the whole thing is a mess that should have been sorted out years ago. As one of the 4 vendors that actually has a compatible implementation of Microprofile 6 and above the two WG should have merged years ago with innovation occurring in Jakarta ee as standalone specs then maturity being signalled by adoption into a platform spec. 

On this particular point as Kenji stated MicroProfile explicitly voted on the pull model 5 years ago!!!!  https://docs.google.com/document/d/1VQ5cvzhVhKYr27FKC1tVmf081eGLSNiuX-dhQ2BxItc/edit?pli=1&tab=t.0#heading=h.7e20q7f70ond  which includes the explanatory text

"Downstream consumers will probably require a fork (with changing package names)  to meet the downstream projects requirements."

This should not be controversial as it is rehashed continually.

While we have the same debates the market does not care and moves on.

Steve

From: config-dev <config-de...@xxxxxxxxxxx> on behalf of Emily Jiang via config-dev <confi...@xxxxxxxxxxx>
Sent: Friday, February 21, 2025 11:25:40 am
To: Jakarta Config project developer discussions <confi...@xxxxxxxxxxx>; MicroProfile <microp...@xxxxxxxxxxxxxxxx>
Cc: Emily Jiang <emij...@xxxxxxxxxxxxxx>; Jakarta EE specifications <jakarta...@xxxxxxxxxxx>; Arjan Tijms via jakartaee-platform-dev <jakartaee-p...@xxxxxxxxxxx>
Subject: Re: [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12 and MP.next

I strongly disagree with forking MP Config to Jakarta with namespace changes. This introduces unnecessary headaches and namespace clashes in the IDEs. Why cannot Jakarta EE adopt MicroProfile Config as it is and job done? No more hassle.

The namespace update is purely artificial and causes too many headaches and version matching. In order to continue the forking and namespace changes, can anyone show me the rule of Jakarta not allowing the use of MicroProfile specs first? 
Emily

On Fri, Feb 21, 2025 at 11:02 AM werner.keil--- via config-dev <confi...@xxxxxxxxxxx> wrote:
Kito/all,

Thanks for forwarding this, although the quote of quotes of quotes makes it very hard to read.

I fully agree with Otavio's message that both are developed under the Eclipse Foundation, and users of a product don't really care, if it was developed in repository A or B.

However, what Roberto outlined earlier about continuous copying between MP Config and Jakarta Config makes absolutely no sense.

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.

MicroProfile consumes Jakarta EE, so there is no MP application or platform without a Jakarta EE platform, at the very least the Core Profile. So Jakarta Config is expected to be available in every profile. If the MP Config API was to co-exist with Jakarta Config forever, then applications would have to exclude one of them from their build system, otherwise they risk confusion or even mixing them in the same project with unforseen and unpredictable consequences. Especially if a Jakarta EE application using Jakarta Config API also wanted to use certain MP features like OpenTelemetry, Health, etc. internally configured via MP Config, but potentially even a different version of the API, if e.g. MP 8.1 used a new version of MP Config while Jakarta EE was still on 12 or 13 based on an older MP Config API.

If the API is a drop-in-replacement then nothing keeps the MP projects from using the Jakarta one after the next release. And it does not really matter, if it was maintained in https://github.com/jakartaee/config or 
Otherwise everyone, most importantly developers and users of both MP and Jakarta EE would face a "config hell".

Regards,
Werner


From: config-dev <config-de...@xxxxxxxxxxx> on behalf of Kito D. Mann via config-dev <confi...@xxxxxxxxxxx>
Sent: Friday, February 21, 2025 4:16 AM
To: Jakarta Config project developer discussions <confi...@xxxxxxxxxxx>; microp...@xxxxxxxxxxxxxxxx <microp...@xxxxxxxxxxxxxxxx>; Kito D. Mann <kito...@xxxxxxxxxxx>
Cc: Kito D. Mann <kito...@xxxxxxxxxxx>; microp...@xxxxxxxxxxxxxxxx <microp...@xxxxxxxxxxxxxxxx>
Subject: Re: [config-dev] [EXTERNAL] Re: [microprofile] Config for Jakarta EE 12 and MP.next
 
Re-sending...
On Feb 17, 2025 at 4:35 PM -0500, Kito D. Mann <kito...@xxxxxxxxxxx>, wrote:
 
I think that, in the case of config, other specifications can just specify the accepted config properties, regardless of how these properties are provided. The TCK could use system properties as a common config source. 
 
Then Microprofile umbrella can state that these properties are supplied by MP Config, Jakarta EE Platform would state they are supplied by Jakarta Config. Jakarta Core profile wouldn't need to include Jakarta Config. Or it could, but then MicroProfile would state that Jakarta Config is not required. I'm sure there's a way to define all this in a simple way so that everybody is happy.

I think that makes a lot of sense. Each spec just says what it needs from a "Configuration Provider" and that provider would be either MP Config or Jakarta Config. 
 
With all that, I share the same sentiment with Reza. I always hoped that MP would tend to donate APIs to Jakarta after they become stable, and then completely rely on the Jakarta version of the API.
 
I agree with this sentiment as well... 
 
We need to also keep in mind the perspective of the end users... they want a "normal" configuration setup that "just works" with all of the different parts of the app. And it would be confusing to have two different namespaces with the same classes. It's also confusing for the end user to have two different Config specifications, even if they're roughly the same.
 
___

Kito D. Mann | @kit...@mastodon.social | LinkedIn
Java Champion | Google Developer Expert Alumni 
Expert consulting and training: Cloud architecture and modernization, Java/Jakarta EE, Web Components, Angular, Mobile Web
Virtua, Inc. | virtua.tech
+1 203-998-0403

* Enterprise development, front and back. Listen to Stackd Podcast.
* Speak at conferences? Check out SpeakerTrax.
On Feb 17, 2025 at 3:20 PM -0500, Ondro Mihályi <mih...@xxxxxxxxxxx>, wrote:
 
I think that, in the case of config, other specifications can just specify the accepted config properties, regardless of how these properties are provided. The TCK could use system properties as a common config source. 
 
Then Microprofile umbrella can state that these properties are supplied by MP Config, Jakarta EE Platform would state they are supplied by Jakarta Config. Jakarta Core profile wouldn't need to include Jakarta Config. Or it could, but then MicroProfile would state that Jakarta Config is not required. I'm sure there's a way to define all this in a simple way so that everybody is happy.
 
With all that, I share the same sentiment with Reza. I always hoped that MP would tend to donate APIs to Jakarta after they become stable, and then completely rely on the Jakarta version of the API. But that's not necessary, and I think anything is better than the current state, when many implementations rely on MP config even for their Jakarta EE functionality, or even worse, MP parts support MP Config while Jakarta EE parts don't.
 
All the best,
Ondro
 

On Mon, Feb 17, 2025 at 8:29 PM Reza Rahman via config-dev <confi...@xxxxxxxxxxx> wrote:
 
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 <confi...@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 <microp...@xxxxxxxxxxxxxxxx>
Date: Monday, February 10, 2025 at 18:20
To: microp...@xxxxxxxxxxxxxxxx <microp...@xxxxxxxxxxxxxxxx>
Cc: confi...@xxxxxxxxxxx <confi...@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 <microp...@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 <microp...@xxxxxxxxxxxxxxxx> wrote:
 
From: microp...@xxxxxxxxxxxxxxxx <microp...@xxxxxxxxxxxxxxxx> on behalf of Reza On Wednesday, February 5, 2025 at 07:58 m.reza...@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 <microp...@xxxxxxxxxxxxxxxx> RC wrote:
 
RC> A few comments inline. Thank you!
 
On 4 Feb 2025, at 18:18, Jared Anderson via config-dev <confi...@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...@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...@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...@xxxxxxxxxxxxxxxx.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/CAECq3A-%2BjFdx4gHGky0Aw6-39J1ne1jWvoL%2BSdr87Cb1FHcYpA%40mail.gmail.com.

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

 

 
 
_______________________________________________
config-dev mailing list
confi...@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
config-dev mailing list
confi...@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
 
 
--
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...@xxxxxxxxxxxxxxxx.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/CABd%3DrHcziJ51i1tm1Y-Xth3A7ij-x6wzRuEbAJX83fTmqjkXEQ%40mail.gmail.com.
 
_______________________________________________
config-dev mailing list
confi...@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


--
Thanks
Emily


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

--
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...@xxxxxxxxxxxxxxxx.
--
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/5b300650-1d95-45a4-bc1e-30f7e0a8d34bn%40googlegroups.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


--
Thanks
Emily



--
Thanks
Emily

Back to the top