--------------------------------------------------- Kevin Sutter STSM, MicroProfile and Jakarta EE architect @ IBM e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutter
Lloyd <david.lloyd@xxxxxxxxxx> To:
EE community discussions <jakarta.ee-community@xxxxxxxxxxx> Date:
Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta
On Fri, Apr 3, 2020 at 9:56 AM Werner
Keil <werner.keil@xxxxxxxxx> wrote: > > All of these are defined by standard bodies with strong compatibility
requirements like W3C or the JCP. > > The namespace is not so much a problem as the "Not My Problem"
attitude the MP stakeholders expressed in their vote for the option called
"Pull". That is even a stronger argument against using a feature
like MP Config as is instead of a "fork" or writing something
heavily inspired by it from scratch in Jakarta EE.
Who would do the work? We're rapidly innovating in MP Config right now, learning a lot about the problem space and processing real user feedback, and applying that knowledge in a way that can be consumed today. If you fork, you're going to end up with probably a separate body of people (where will these people come from?), developing a separate piece of software from scratch which, instead of being based on working and useful implementations, is top-down designed and has no initial implementations - discarding that learning process just to spite MP out of impatience AFAICT. It seems silly to me.
If the bar for Jakarta EE is stability, you can't clear that bar by crapping out some code and calling it "stable", no matter how brilliant you are. It has to be proven in the laboratory of the real world - an iterative process. MP Config is going through that process right now, in fact, and rapid innovation is the direct result of that. We're not breaking things for fun, and in fact we put forth some effort to not break things anyway (despite being allowed to). Perhaps there will be a time where most people are mostly happy with it and few new use cases arise, rendering the specification mostly quiescent, but until that time, anything you do to call the field of standardized configuration in Java "stable" will effectively be a lie, just
to check a box. Such lies do little to enhance the reputation of specification bodies which perpetuate them.
> Not giving a damn about compatibility requirements means, Jakarta
EE probably would have to fork the TCK for such MP feature anyway because
if the project suddenly decides to run the TCK with Spock or JUnit 5 instead
of TestNG while the Jakarta EE platform has other foundations of its TCKs,
then Jakarta EE might as well just fork the whole of it instead of bothering
with a TCK fork or trying to integrate it somehow without support by the
I guess it depends on how much you enjoy doing busy work. I for one really dislike doing it; any time spent working on a (possibly inferior) parallel specification to one that is in wide use is time wasted, to me; I can only imagine that my co-collaborators on MP Config feel similarly. Who would be left to work on the specification when all of the experienced engineers don't want to do it? What kind of specification would that be?
It's far more rational to let MP Config continue to do the "dirty work" of figuring out what works and what doesn't work, and then revisit the question at a more appropriate time. Consuming MP Config could be a far more attractive option in, say, 12-18 months time. Moving it wholesale to Jakarta might similarly be a more reasonable option at that time. It's better than spending 12-18 months arguing over a new specification anyway - how tiresome that would be. -- - DML