| Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration. |
To be honest, what you are suggesting is even more worrisome. What it implies is that there will be two standardization models in enterprise Java that are highly duplicative and basically competing. That will hardly reduce the fragmentation, confusion and divisiveness. That is why many of us would like to see Jakarta become the unifying standardization model. I would say this is all the more reason to fork and standardize right now. Reza Rahman Jakarta EE Ambassador, Author, Speaker, Blogger 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: Scott Stark <sstark@xxxxxxxxxx> Date: 4/6/20 10:40 AM (GMT-05:00) To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration
as Jakarta Configuration. model as Jakarta, so it seems a little backhanded to ignore that. So further standardization is some form of duplication of standardization. Simply because other Jakarta members are not clear that a fork is the best way to incorporate MP specs into Jakarta does not mean we might eventually settle down to that. There were discussions about employing an LTS model in MP, transitioning specs to mature vs innovating, etc. in the pull thread discussion. Eventually those will have to be compared against a simple fork, but this is an EE10 timeframe discussion that is not a priority for me right now. On Mon, Apr 6, 2020 at 6:41 AM reza_rahman <reza_rahman@xxxxxxxxx> wrote: > > I very much empathize with folks like Anthony as we are essentially in the same boat. One of the most frustrating aspects of MicroProfile is the radically changing goals that does not seem terribly consistent or entirely rational. > > My expectation has always been and remains that MicroProfile features that are mature enough will be properly standardized into Java/Jakarta EE - quite possibly into a new profile targeted for microservices. In no way do I see this diminishing the value of MicroProfile. Indeed historically standardizing features from any source typically enhances the value and usage for both the source and the open standard. I also can't think of any example of something being standardized "as-is" out of something that itself is not an open standard. I really have a hard time understanding why any of what Otavio is proposing is radical in any way from a rational, technical standpoint. > > With regards to the premature standadization viewpoint, it would be helpful to understand precisely what the short term roadmap is and why that work would not be appropriate to do within an open standard effort instead of an open source project that isn't an open standard and probably should never aim to be due to it's explicit focus on innovation. > > Are there other unstated factors at play behind the objections to further standardization? If so, why not state them explicitly so they can be evaluated and discussed? > > Reza Rahman > Jakarta EE Ambassador, Author, Blogger, Speaker > _______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community |