This model is true of a number of specifications. E,g the REST client api could be part of JAX-RS, some of the work on concurrency should be introduced in Jakarta Concurrency. Reactive Messaging
should inform the next version of Jakarta Messaging. All would require some change to the specifications during the process.
If the view is that MP moves fast and breaks things and Jakarta EE builds a coherent stable platform then we should be incorporating ideas created in MP and developing them in the Jakarta WG in the
Jakarta namespace.
Steve
From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx>
On Behalf Of arjan tijms
Sent: 02 April 2020 01:01
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
Hi,
A more thought provoking case is pulling-in MP JWT Auth, but not as a full standalone spec, but as one of the standard authentication mechanisms in Jakarta EE Security. Potentially we can leave out the very elaborate multi-level conversion
"sub-specification" of JWT Auth (which details injecting the JWT payload as many different types).
IFF we would do that, do we keep the spec text in Jakarta EE manually in sync with the spec text in MP, or do we reference the MP text? I case of a fork I guess it's the former, but wonder what people think.
Hi
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.
That was my understanding as well when I read the proposals.
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
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|