Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [config-dev] [External] : Re: Discussion about Jakarta Config on MP Technical meeting

Thank you Dmitry for the update! You beat me to it (had Friday off for a long weekend)! I also agree that we had a very productive meeting on Thursday to discuss MP Config. I think fixing some issues there has a bigger benefit than doing something different here.

For MP Config, the group can start working on the issues straight away as I will create a branch for MP 5.0 very soon so that the master branch can be used for the issue deliveries.


On Mon, Aug 16, 2021 at 12:28 PM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:

We had a very productive meeting last Thursday and I have a feeling that both teams are more or less on the same page here. We indicated some issues in MP Config which should be fixed before it’s transition to Jakarta Config:


We haven’t discussed the transition process itself on the meeting.


My vision is


  1. We work together on fixing indicated issues in MP Config
  2. Last version of MP Config gets released.
  3. MP Config gets transferred to Jakarta with the only change in Maven coordinates and package name
  4. First version of Jakarta Config is released


I am skipping all required compatible implementation and TCK work assuming that it has to be done before Jakarta Config 1.0 release.


I don’t know how this plan would correlate with MicroProfile 5.0 release planned in October 2021. The idea was that adopting jakarta.* specifications would be the only change. It plays against my vision above.


What the group think about it?


-- Dmitry



From: config-dev <config-dev-bounces@xxxxxxxxxxx> On Behalf Of Mark Struberg
Sent: Thursday, August 12, 2021 11:59 AM
To: Jakarta Config project developer discussions <config-dev@xxxxxxxxxxx>
Cc: David Blevins <dblevins@xxxxxxxxxxxxx>
Subject: [External] : Re: [config-dev] Discussion about Jakarta Config on MP Technical meeting


Hi Dmitry!


My personal view inside:


Adding David because on that call he had questions regarding compat.





Am 09.08.2021 um 19:09 schrieb Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>:


I listened a recording of the latest MicroProfile technical meeting where Jakarta Config was discussed ( I don't agree in a way how Jakarta Config was presented there, it doesn't reflect the real situation. I even more disappointed that it was presented by Emily, who is one of the leaders.

The first and fundamental mistake is to think that Jakarta Config tries to build a new spec from scratch. It's not our goal. We want to get maximum from MP Config but before doing it we want to understand what we want to build.


I think what a spec needs to do is to have an open mind. In the last meeting I recommended to take a step back and look at whether there is a better solution on the scene NOW (remember that the technical choices in mp-config date back to 2010 ultimately coming from Apache CODI still, then moved over to DeltaSpike, then mp).

I'm biased of course and I like the design of mp-config. But probably there is something new around, and IF SO then NOW is the time to review it!

Because when moving from mp-config up to Jakarta Config then NOW is the time to potentially break things - because it has a different package name anyway and people have to touch the code in any case. Ideally just a search&replace. But if there is a huge benefit in picking up a new approach (IF there is any!) then NOW is the time to review it and discuss if it's worth it.

The main concern about MP Config is that it was not build in truly vendor-neutral way. Technically it's not a specification at all because it was not created under any specification process. It's an open source API created by a few enthusiasts mostly from RedHat and IBM.


*harrumph* the main design decisions have been taken over from the community really. Just look at the authors list. 


There was also a long discussion about whether mp-config should kind of stop existing and just rename the packages.

That ignores that there are projects out there using mp-config already.


And it IS possible to support both at the same time.

I've done the same using mp-config and DeltaSpike config in the same codebase. DeltaSpike picking up mp-config ConfigSources and vice-versa. The only part to take care is to not introduce cycles, but that's pretty much it. With this approach you could read/write from both systems with a kind of 'bridge'. And that way mp-config could also still evolve (even if I think it will not happen). But it IS available for existing consumer projects. Think about some library jars which cannot just get migrated over from mp-config to jakarta-config without trashing another project.



Although, I'm not saying that it's a bad API, but Jakarta cannot take it as it is without a deep review, without making sure that it fits all Jakarta EE requirements and without a consensus between all participating parties. This is what Jakarta Config team is currently working on. We are trying to set some requirements and after that we'll decide how MP Config should be changed to address them. This new spec must become the only config spec suiting both Jakarta EE and MicroProfile. I agree that there is no need to have 2 configs. 

Talking about changes. We haven't finished our analysis and it's too early to provide a summary. So far, MP Config fits well into our requirements, but there are a few issues which I consider minor. 

MicroProfile team pushing hard in all directions to force Jakarta Config to take MP Config as it is. We already had a several discussions about it. We will discuss it again on CN4J meeting. I personally believe that it's not right open source way of doing things. Please stop doing it! I personally invited all MP Config committers to Jakarta Config team. So let's work together to build a spec which all parties will be happy with.


-- Dmitry


config-dev mailing list
To unsubscribe from this list, visit


config-dev mailing list
To unsubscribe from this list, visit


Back to the top