I think certainly a sensible next step could be to assess who would be involved in a Jakarta Configuration project, including the orginal folks that filed the equivalent JSR as well as potential early implementors. Of course part of that needs to be assessing if it would be premature standadization. Given how long this concept has been around especially considering prior art done in the Spring space, my current view is that it is indeed mature enough for standardization, possibly for inclusion into Jakarta EE 10.
Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- From: Werner Keil <werner.keil@xxxxxxxxx> Date: 4/3/20 12:13 PM (GMT-05:00) To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
Well your colleagues at Red Hat did what was necessary with the Injection spec, so there should be enough people to contribute if the majority of Jakarta EE stakeholders came to the conclusion, that MP as a whole or certain specs were not usable the way they are run there sure are people and contributors to some other projects that would also do the same here. Look at Helidon Config which goes way beyond MP although it contains a compatibility layer but it has its own separate more powerful API. Spring config is probably the most mature and widely used framework and Pivotal is also a Jakarta EE member. Whether or not it wishes to get involved there remains to be seen, but take examples like Batch, it was very involved and is also among the most popular implementations of Jakarta Batch. Needless to say a large number of the features and annotations in MP Config were heavily inspired by Spring, so its contributors would be a good candidate for this and also benefit from using it in the future.
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)
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.
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 authors.
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
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|
