I listened a recording of the latest MicroProfile technical meeting where Jakarta Config was discussed (
https://www.youtube.com/watch?v=zDpT_Gu2uX4&t=774s). 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
