| Re: [jakarta.ee-community] Options for Jakarta EE and MP alignment |
As a consumer of Microprofile and JakartaEE this one makes the most sense to me. Microprofile already depends on multiple JakartaEE specifications, promoting stable and mostly finished specifications to Jakarta seems obvious. This implies that both groups have a similar vision for a certain specification, otherwise fork is inevitable.
Then again, even a fork is really no worse than the current situation when you have absolutely no interop between custom vendor configurations in EE space and mp-config.
Best regards, cen
Use MicroProfile as a flow to Jakarta EE Specifications
In this model, we'll keep the MicroProfile as a space to innovate and get more maturity to the project and then we move the MicroProfile API to Jakarta and makes MicroProfile one as deprecated.
Pros
- Jakarta EE can pick and choose which MicroProfile APIs are appropriate.
- Jakarta EE still have a place to innovate
- There is not support to two API later, once the project when became Jakarta EE, it will deprecate the MicroProfile API.
Cons
- It requires a move of the namespace for the API
- Developers will have the migration process every time that the API became a Jakarta EE.
- In the begging, the provider will have to support both APIs for awhile.
On Fri, Apr 3, 2020 at 8:24 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
_______________________________________________All,
There has been a recent debate on to fork or not to fork MicroProfile Config. I wanted to outline what I feel are the 3 options available to the Jakarta EE community in adopting MicroProfile apis. The last two options are predicated on the MicroProfile community bootstrapping a working group and putting their apis through a specification process.
Graduate MicroProfile apis into Jakarta EE Specifications
In this model Jakarta EE takes relevant MicroProfile apis as inspiration and starts a specification project to move the ideas from the MicroProfile api into the jakarta namespace and create an equivalent Jakarta EE specification that can be integrated across the platform in a unified and coherent manner.
Pros
Jakarta EE can pick, choose and adapt ideas from MicroProfile to its needs to ensure consistency across the platform
Jakarta EE is free to diverge from the MicroProfile api if it is developing in a direction which Jakarta does not require
All Jakarta EE apis are in the same namespace and under control of the Jakarta EE community so can retain backwards compatibility.
Any product could be both Jakarta EE version X compliant and MicroProfile version Y compliant.
Cons
It requires a move of namespace for the api
Developers have 2 apis to choose from if they develop to both the latest MicroProfile and Jakarta EE apis in a runtime that supports both
It requires more effort to maintain a potentially diverging api
The Jakarta EE Platform Release incorporates a MicroProfile Platform Release by Reference
In this model Jakarta EE version X platform specification could declare it incorporates the entirety of MicroProfile version Y by reference.
Pros
Jakarta EE is incorporating a well defined MicroProfile platform and can ensure specifications can integrate with it where possible.
No move of namespace of MicroProfile apis therefore only 1 api to support and develop to.
A runtime can be both Jakarta EE X compliant and MP Y compliant.
Cons
An individual runtime will likely be behind the curve on MicroProfile compatibility as it will be difficult to support 2 versions of MicroProfile in the same product version.
It may not be possible for Jakarta EE to retain backwards compatibility across platform releases as MicroProfile allows breaking changes across major versions.
Jakarta EE developers are using two namespaces.
The MicroProfile api may develop in a direction of no relevance to the Jakarta EE community as they are separate communities.
By referencing a whole MicroProfile platform release the Jakarta EE platform will incorporate apis which may have no relevance to Jakarta EE developers or are not stable.
Jakarta EE incorporates a subset of a MicroProfile platform release
In this model a Jakarta EE version X platform specification could cherry pick individual MicroProfile apis for inclusion by reference. For example MP Config X and REST Client Y …
Pros
Jakarta EE can pick and choose which MicroProfile apis are appropriate.
No move of namespace of MicroProfile apis therefore only 1 api to support and develop to.
Cons
An individual runtime may not be able to be MicroProfile compliant and Jakarta EE compliant or it will be behind the curve on MicroProfile compliance due to missing apis or conflicting api versions.
It may not be possible for Jakarta EE to retain backwards compatibility across platform releases as MicroProfile allows breaking changes across api major versions.
Jakarta EE developers are using two namespaces
The MicroProfile api may develop in a direction of no relevance to the Jakarta EE community as they are separate communities.
If there are other options feel free to shout and I can develop a doc for comments.
Steve
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Otávio Santana
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community