| Re: [jakarta.ee-community] Options for Jakarta EE and MP alignment |
> 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
Since MicroProfile even started with a subset of Jakarta EE and each spec or feature builds on at least one or more Jakarta EE specs, maintaining 2 APIs would not happen for more than maybe one release. Then as Eclipse does all the time such feature in MP shall be archived (turned read only) and the latest version of MicroProfile simply adds another Jakarta EE dependency to that new graduated spec.
Only if developers had to maintain different versions of their solutions based on MP1, 2 or higher including the underlying Java or Jakarta EE platforms, they have more effort, but that's the same everywhere, if you have a Java EE 7 and Jakarta EE 9 solution to work on in parallel, that's more to learn and maintain.
Regarding options 2 and 3, both ways of incorporating either the whole MP "platform" or individual features will suffer from two separate working groups and release cycles for Jakarta EE and MP which now seems the desired approach.
MP already lags behind, it shows no evidence of a Jakarta EE 9 compliance although the vast majority of Jakarta EE specs already published the first milestones (notably absent CDI 3, but it could have something to do with most contributors having to maintain at least one MP feature beside it?;-)
Werner
_______________________________________________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