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.

What is happening on this thread is really a manifestation of what happens when you have two things that are very closely placed in the same space but have a very unclear relationship. That is why folks like myself would like to see a relationship defined before it is just too late and too many disputes have gone unresolved for too many people. Worse yet is loss of ecosystem diversity as a result.

There is a very sensible possible relationship that values each for what they are and can be together. I sincerely hope the right people can see this and can envision where this might be going if status quo persists too long. It should be perfectly fine cleanly transitioning something from innovation to standardization. Mixing up those messages and brands is risky to say the least and possibly completely unnecessary.

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/6/2020 4:09 PM, Alasdair Nottingham wrote:

The whole stability vs innovation discussion in MicroProfile is one that has caused a lot of debate and discussion over the years. The original intent was to allow breaking changes if they are in the interest of the API and its user community. It isn’t a free for all that we break things every time.  A case in point when MicroProfile Health 2.0 introduced support for Liveness and Readiness probes the previous health check support (which to be honest was not useful) was retained, despite the fact it could have been removed.

I think the instability of MicroProfile is being very much over stated in this thread.


On Apr 6, 2020, at 3:59 PM, Ryan Cuprak <rcuprak@xxxxxxxxx> wrote:

  I agree with your points. I was under the impression that the goal of MicroProfile was to get Java EE moving again and specifically address microservices and cloud shortcomings in the platform. Currently, my impression is that MicroProfile is antagonistic towards Jakarta EE when I was expecting the two would merge together. I thought that MicroProfile were the people who banded together to get things done when Oracle was the obstacle.

  With these discussions, MicroProfile is looking less attractive because of the apparent emphasis on breaking things over stability (at least in discussions). There needs to be balance here so that an application can make money before it needs to be updated. The argument that MicroProfile is more agile than Jakarta EE is a bit confusing, I thought that was part of the reason for moving Java EE to Eclipse and changes the processes so that Java EE would be more agile.

  With governance of MP, I am not sure if the “pull” vote means that issue has been decided. If that decision is binding (like Brexit), then I think Jakarta EE will need to move forward.

  I always looked at Jakarta EE as a standard. Once everyone more or less agrees on a way of doing things.

  Separate note, I am shocked at the number of emails on this subject. I wonder if more lines of emails have been spilled on this subject than code written in MP Config =)
So we wouldn’t have to throw the towel in and switch to Spring.

On Apr 5, 2020, at 2:00 PM, Anthony Vanelverdinghe <> wrote:

As an end user, I'm looking for a comprehensive, consistent, integrated platform, composed of specifications & with an overarching platform spec. That's what Java EE has always offered, and Jakarta EE should do whatever necessary to maintain that. And yes, even just seeing multiple package namespaces in the Javadoc wouldn't make sense to me & break the idea of a consistent, integrated platform.

As an observer, I've been following the evolution of MicroProfile with increasing astonishment: of the 4 goals in the initial proposal's scope [1], it seems to me that 3 of them have already turned into non-goals by now. When Java EE was donated to the Eclipse Foundation, I was looking forward to the synergy between MicroProfile & Jakarta EE, exactly because I assumed the initial goals of MicroProfile still held true, and mature specs would be migrated to Jakarta EE etc.

I'd very much like to see Jakarta EE move forward, so I'm fully with Rudy, Reza (who always does an impressive job at voicing the community's (or at least my) concerns eloquently), Steve, Ondro et al. here.

Kind regards


On 05/04/2020 11:55, Ondro Mihályi wrote:
It's not need to search through the history, the Pull statement that was selected in the vote mentions enough. For reference, I added full Pull text at the end of my email. It literally says that JakartaEE would need to manage conpatibility and namespce among others, and that's what Otavio's suggestion addresses. It also says it's up to JakartaEE to resynch with changes in MP, which can only be done with a fork in case MP introduces an incompatible change which isn't acceptable for JEE.

I voted for the pull mechanism only because I saw that any other solution would cause neverending disputes and I expected that JakartaEE would be free to choose what to do with MP specs. And now I see that many people who also voted for Pull are against JEE considering a fork and are introducing new disputes. I'm frankly sad about that. We should explore what's possible and makes sense and choose the best option for JEE without any prejudices.

For reference, the full MicroProfile Pull statement:

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.

Dňa ne 5. 4. 2020, 11:06 reza_rahman <reza_rahman@xxxxxxxxx> napísal(a):
If this is an accurate perception of what happened it is honestly troubling and goes back again to that question of good faith in intent, words and actions.

Can you point to anything that still exists clarifying a known, intentional expectation of a fork as a result of the pull vote? I would certainly like to see it for myself. I tried to follow as closely as I could but it is entirely possible I missed some things. Maybe it was in yet another lengthy hangout recording for which minutes never seem to be shared?

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: Rudy De Busscher <rdebusscher@xxxxxxxxx>
Date: 4/5/20 3:46 AM (GMT-05:00)
To: Jakarta EE community discussions <>
Subject: Re: [] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.

Can everyone who voted for PULL, stop complaining against the Jakarta people for exactly doing what you have voted for.

The word fork was removed last minute from the pull text but it was always part of it during the discussions during months and the intention.  But this downstream project is exactly doing what is in the PULL text, defining the lifecycle, compatibility requirements and namespace.

And don't start about having 2 different hats. There is only 1 world, 1 reality in which Jakarta does exactly what is needs to do based on the outcome of the PULL vs PUSH vote.

The fork is the only viable solution if vendors want to keep combining Jakarta EE and MicroProfile in one product when some of the MP specs are used by Jakarta Specs.

On Fri, 3 Apr 2020 at 20:11, David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
You are simply factually wrong in this regard.  You're defining
"caring about compatibility" as being synonymous with "forcing strict
compatibility rules", when this is not true in any respect.

I voted "Pull" because the chief goal of MP ought to be to meet user
needs effectively and quickly, even if that means (in the worst case)
bumpy compatibility at first.  As I said, compatibility is a quality
measure (just one of many) and it arises from a good specification.
Making a specification be compatible doesn't make it good or useful.
It's far better to add compatibility restrictions *after* the
specification is already stable, rather than to add such restrictions
to a specification that is still rapidly developing (thereby greatly
diminishing its usefulness in the name of stamping a logo on it in the
short term).  This is (IMO) a good indicator of when it makes sense to
"graduate" a spec into Jakarta.  The consumers of Jakarta are looking
for long term stability, and that comes from quality, not from a
compatibility contract.

Voting "Push" would have done nothing to improve the quality of
specifications and would have obstructed the process of cross-vendor
standardization - an already inherently politically and socially
obstructive process.  It was a very cynical option IMO.

On Fri, Apr 3, 2020 at 12:55 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
Everyone who voted for this "Pull" option voted against compatibility and supporting it, not sure how many votes Red Hat got there and who was eligible but the majority voted for the "I don't care about compatibility" option, did you vote for "Push"?

On Fri, Apr 3, 2020 at 7:33 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
AFAICT the only people claiming that MP doesn't care about
compatibility are MP detractors.  MP doesn't *prioritize*
compatibility, but I for one *care* about it quite a lot.  When your
first priority is meeting use cases, then compatibility becomes a
quality measure: the easier it is to retain compatibility in the face
of new use cases, the more likely it is that the specification is
already useful for use cases beyond those originally imagined.  The
more useful a specification is, the wider its adoption.

On Fri, Apr 3, 2020 at 12:18 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
And especially one claiming it doesn't care about compatibility or the consumers of its frameworks or APIs while the other by definition has to.


On Fri, Apr 3, 2020 at 7:11 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
Hi David,

I agree nobody wants to duplicate effort. Which is why it is non-sensical to have two separate specification bodies defining specifications which are intertwined as these discussions on both sides demonstrate.


-----Original Message-----
From: <> On Behalf Of David Lloyd
Sent: 03 April 2020 16:49
To: Jakarta EE community discussions <>
Subject: Re: [] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.

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.

_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit


_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit


_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit

_______________________________________________ mailing list

To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit

Back to the top