[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
Steve
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.
Heiko
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Ivar
Grimstad
Jakarta
EE Developer Advocate |
Eclipse
Foundation, Inc.
Eclipse
Foundation:
The Platform for Open Innovation and
Collaboration
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
