|Re: [config-dev] [External] : Re: Discussion about Jakarta Config on MP Technical meeting|
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
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?
My personal view inside:
Adding David because on that call he had questions regarding compat.
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.
*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.
Back to the top