| 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. 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: 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! -- - 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 |