Just to be clear, I prefer we centralize this particular discussion in the Jakarta EE community alias, so I am including it here.
While there is a time to discuss things amongst ourselves here, I don't think it is right for this particular topic. Sorry if that was not clear in my initial mail forward.
I am similarly trying to do the same for folks that just respond on Twitter but don't seem to want to get on a mailing list. Especially as part of leadership, consider doing some traffic guidance for this particular discussion?
I do hope we get to some kind of definitive decision soon on this topic so we don't keep needing to do this.
Reza Rahman
Jakarta EE Ambassadors, 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: Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx>
Date: 4/3/20 4:14 AM (GMT-05:00)
To: Reza Rahman <reza_rahman@xxxxxxxxx>
Cc: Jakarta EE Ambassadors <jakartaee-ambassadors@xxxxxxxxxxxxxxxx>
Subject: Re: [jakartaee-ambassadors] Fwd: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
Hi all, I really appreciate all the opinions expressed here. But, since this is a Jakarta EE discussion, I strongly urge everybody to remove their MicroProfile hat and look at things from the Jakarta EE perspective. I had expressed my opinions as a MicroProfiler on the MP mailing list, we voted, and chose to go with the Pull model, regardless of what the Jakarta EE community thought about it. But I feel that MP doesn't have any right to dictate how Jakarta EE should consume their specs. Therefore I'm writing with my Jakarta EE hat on now.
The pull model and the premise of frequent breaking changes makes it impossible for Jakarta EE to consume MP specs without a change. JEE specs might define an optional behavior if the container also supports MP but can't rely on anything from MP. That's a fact, it doesn't help to encourage Jakarta EE to depend on "mature" MP specs or any LTS releases. Will MP maintain such LTS releases and evolve them without breaking changes? No, there's no prospect of that. So there can't be any LTS releases of MP. If JEE needs to evolve such LTS release, it would need to fork them anyway.
If both MP and JEE communities want to have a common config spec, the only way with the MP pull model is to transfer whole Config spec to Jakarta EE and deprecate MP Config in favor of Jakarta Config. MP would lose the momentum in the Config spec but it's the only sensible way I see to unify config in both MP and JEE. MP Config spec is mature enough for that and Jakarta Config can provide enough extension points to continue innovation via extensions within MP.
For other specs, I see no problem to have an MP variant that moves fast, and a Jakarta variant that is stable and undergoes the JEE specification process. With different namespaces to avoid conflicts. But this can only happen if enough people would be interested to put effort to it.
May I kindly ask that folks here - especially folks in leadership
- give some of this some thought and express their own genuine
opinions on the Jakarta EE community alias?
I understand that for some folks this might seem repetitive. Let
me share from my experience of years of multi-lateral
collaboration in the JCP - some times repeating yourself
patiently, consistently and persistently is the way to make the
right thing happen finally.
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.
-------- Forwarded Message
--------
Subject:
Re: [jakarta.ee-community] Fork Eclipse MicroProfile
Configuration as Jakarta Configuration.
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.
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.
PULL TEXT
----------------
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.
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
would
prevent the two from drifting apart. Or that
contributors have to
constantly
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.
