Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Ja

[David Lloyd <david.lloyd@xxxxxxxxxx>]

> The problem with the new MP WG is, that it may well argue 12-18 months over another "Pull vs. Push" approach with no usable outcome and no result Jakarta EE or other platforms and frameworks (including the likes of Helidon, I won't even mention Spring because a CDI-only approach automatically disqualifies it from being used by Spring)

Such an argument would not be likely, since "Pull" was already
effectively agreed upon (which is a thing that spec bodies have to do)
- and the agreement seems nearly unanimous - but in any event "Pull
vs. Push" has mostly to do with attempting to *force* spec teams to do
one thing or another, AFAICT, and a lot less to do with voluntary
collaboration, which is (IMO) necessarily the mother of a good quality
specification and which is what you *really* need in order to move or
fork the specification in a way that isn't reductive and wasteful.

I happen to know of a fairly diverse group of people who are already
collaborating successfully (through consensus even!) on a
specification which is rapidly improving in quality, while also
already being used and promoted by multiple industry frameworks and
users.  This group of people are quite reasonable and would possibly
even be amenable to a wholesale move at some point in the future, if
it can be done in a sane manner.  Attempting to force such a move
(through any means) is doomed to failure though, for a multitude of
reasons.

> Not everyone likes to write or improve TCKs, but they are necessary for a platform that has a quality and compatibility requirement like Jakarta EE does.

I'm not opposed to writing or improving TCKs, because ultimately
that's useful work - work we already do in MP Config in fact.  The gap
between where MP Config is today and where a Jakarta Config spec is
expected to be in terms of stability cannot be spanned with more TCKs.
The specification has to be refined, poorly specified or incorrect
behaviors flushed out, and tested in the real world.  TCKs come after
that.  We're doing that work already; why are you so keen to force
others to duplicate it?

-- 
- DML