Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.

Hello folks +1 with steve and reza

Is better to keep the specs separated like reza mention is better use MP config as a inspirational spec for jakarta EE config spec and let each spec evolves in his own pace, the thing that comes to my mind that will be interesting is allow to jakarta EE config spec integrate with other specs like MP config but without lose his own config spec (something like a if you have your config implementation we are ready to use it, if not i have a default one), that will starts to make the jakarta spec more open to others specs under the eclipse umbrella.



On Fri, Apr 3, 2020 at 12:51 AM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
It really saddens me to say this, but given everything that I have been observing for a long time now, I am 100% with Steve. Under the circumstances, I also especially applaud Otavio for getting the ball rolling sooner rather than later. I think Jakarta EE should standardize things like Configuration, JWT and Concurrency using the MicroProfile work as key inspiration but under it's own namespace and as an integral, cohesive part of the overall platform.

Unfortunately IP is not the only issue at play. If Jakarta EE actually does want to be seen as a credible open standard, it also needs to be mindful of things like API/namespace cohesion, life-cycle, process, stability, compatibility, governance, sufficiently broad vendor participation, sufficiently broad community participation, backwards compatibly, a goal of empowering a very broad ecosystem and so many other things for which open source alone is just not sufficient. I also agree that MicroProfile should be a bit more forthcoming about the fact that it really isn't an open standard but rather an open source project that meets market innovation demands by rapidly producing technologies multiple vendors can utilize with a looser sense of compatibility, governance, process, stability and interoperability.

Both can co-exist harmoniously and serve a useful market purpose even if Jakarta EE properly standardizes a pretty limited set of more mature concepts and APIs. The other way around is just incredibly confusing. Having circular version dependencies of co-evolving APIs in projects that are very different in nature seems especially mind bending.

What I had hoped for all along is something like this, except for a mutual harmonious consensus that projects moved over to Jakarta EE need not be evolved in MicroProfile any more and all Jakarta EE projects be mindful of the needs of downstream usage within technologies like MicroProfile or Spring. I am still holding out hope that this might happen despite how things have felt for a while now.

To be honest, I really wish some more people here that we don't usually hear from chime in and tell us how they really see all of this. That's what I have been trying to do with these polls:,

Please folks, speak your mind. This is important stuff and complex stuff. You are the end user. What do you want to see?

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.

On 4/1/2020 11:36 AM, Steve Millidge (Payara) wrote:

I would support a proposal to standardise a config api in Jakarta EE for Jakarta EE 10 based off the MP Config api but properly integrated across the platform.


I agree the pull model really moves us towards forking and moving to the Jakarta namespace if we want to manage stability and integration into the rest of Jakarta EE.


Tbh it would be easier to support both in a single product if they were in separate namespaces.


For reference here is the Pull model that MP voted to adopt.




MicroProfile creates and evolves specifications without regard to downstream consumer requirements (e.g. Jakarta). For example, specification consumers will have to manage items like lifecycle, compatibility requirements, namespace, whether org.eclipse.microprofile is a suitable root package, etc.

MicroProfile can continue to evolve a specification regardless of downstream spec consumers, and it is up to the downstream consumer to decide if it wants to re-sync (or pull ideas from) MicroProfile updates. Additionally, MicroProfile can optionally decide to consume concepts or APIs from downstream projects.





From: <> On Behalf Of Ivar Grimstad
Sent: 01 April 2020 15:58
To: Jakarta EE community discussions <>
Subject: Re: [] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.




On Wed, Apr 1, 2020 at 4:49 PM Heiko W. Rupp <hrupp@xxxxxxxxxx> wrote:

On 1 Apr 2020, at 16:34, Otavio Santana wrote:

> My question is: Does it make sense if we create a fork of Eclipse
> MicroProfile Configuration as Jakarta Configuration?

That is a nice Aprils fool of you :-)


I think the only thing you can make April fools jokes about these days are toilet paper :)


> The project seems stable and it will valuable to several projects such
> as JPA, JMS, and NoSQL.

Is(n't) the main obstacle of just including it that MicroProfile does
not have the IP
protection has, as it does not use the Eclipse Spec Process? If so, I
guess just
waiting on that Process to be used may be as good/quick as a fork and
prevent the two from drifting apart. Or that contributors have to
submit changes to two projects.

But I am sure I am missing some things


The decision within MicroProfile to go with the "Pull" approach to technical alignment actually advocates forking rather than referencing. Jakarta EE can then decide on what level of backward compatibility it wants without relying on the decisions made by MicroProfile. Just my 2 cents.



_______________________________________________ mailing list
To unsubscribe from this list, visit



Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation, Inc.

Eclipse Foundation: The Platform for Open Innovation and Collaboration

_______________________________________________ mailing list
To unsubscribe from this list, visit

_______________________________________________ mailing list
To unsubscribe from this list, visit


Carlos Andres De La Rosa | Software Architect

Mobile: +32465445631  

Skype: carlosa.dlr

Back to the top