|Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.|
Thanks for sharing your thoughts. While I perceive you feel very strongly about this, honestly I personally fully understood your viewpoint from your initial email.
With all due respect I beg to disagree as someone that has spent some time studying the space both from an end user and vendor standpoint. I think this space was already mature enough when the configuration JSR was initially filed. That said, if MicroProfile feels there is still a lot of space for radical changes, perhaps that is indeed a legitimate case for having a stable branch under Jakarta and a slightly more volatile one under MicroProfile. This model certainly applies to things like JMS vs. MicroProfile Reactive Messaging as has been already indicated on this thread.
That all being said, I am keen to hear from folks that are yet to share their perspectives, especially current and future end users of this functionality. Let's put our heads together and try to see what a reasonable compromise might be. There is certainly not a lot of harm in waiting just a bit more if eventual standardization is the good faith objective and the broad consensus really is that Configuration is not mature enough for a more conservative open standard just yet.
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
On Fri, Apr 3, 2020 at 11:44 AM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
-------- Original message --------
From: David Lloyd <david.lloyd@xxxxxxxxxx>
Date: 4/3/20 1:00 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.
> 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.
As someone already working hard to standardize config, I think I can
say with some authority I think that given Jakarta's stability
requirements, it would be a waste of time trying to do so in Jakarta
right now. In the best case, you'd be following along with MP Config
developments (and possibly contributing use cases and/or code to it)
until it is stable anyway. In the worst case, you'd be diverging from
it, due to dismissing accepted use cases, or even possibly for more
petty or political reasons.
In that case, doesn't it make sense to wait for MP Config to mature
some more, to gain yet more ubiquity and uncover any remaining major
use cases that may exist? To me that makes a ton more sense than
throwing away and/or replicating *all* the analysis and research that
has already been done.
Age is no indicator of stability or maturity. You could take some
other existing solution and slap a label on it, but you'd be
dismissing a lot of analysis which reveals use cases that will
definitely be encountered. You'd be accepting a lower quality of
product just to stick the Jakarta name on something sooner rather than
later. Good things come to those who wait!
jakarta.ee-community mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
Back to the top