I would favour this approach for a number of reasons;
-
It keeps the Jakarta EE and MP initiatives somewhat separate as is currently desired by some members of the community and therefore doesn’t require resolution of that problem
-
It solves any IP concerns as the IP is then donated to Jakarta and follows the Jakarta IP process
-
It works for any other api that we may like to standardise and include in the Jakarta EE platform from other api sources outside of MP and/or the EF.
-
It allows more stakeholders, outside of the MP community, to have input into a standard api before it becomes standard and therefore it can evolve maybe in ways the MP community doesn’t want or care about.
-
As the namespaces are different it doesn’t require MP Config to freeze or cease experimentation and Payara or other vendors could choose to then support both the MP config api with its potentially faster rate of change
and the standardised Jakarta Config api
There is a downside that a developer, longer term, would need to migrate to the new Jakarta API but from a Payara POV we can mitigate that impact due to 5 above.
Steve
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Reza Rahman
Sent: 27 September 2019 02:40
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; Phillip Kruger <phillip.kruger@xxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
A fairly simple way to solve this is doing exactly what needs to be done for javax.
* Freeze mature MicroProfile APIs ready to move to Jakarta.
* Move these APIs properly to Jakarta as-is.
* At the runtime level, resolve org.eclipse.microprofile.* to jakarta.*.
* Make future changes under Jakarta.
Reza Rahman
Principal Program Manager
Java on Azure
Please note that views here are my own as an individual community member and do not represent the views of my employer.
On 9/26/2019 8:51 PM, Phillip Kruger wrote:
So are the Config that is proposed under Jakarta a new Config API or the one from MicroProfile ?
* If it's a new one, we then have 2 Config APIs. This is not good for us nor for the users.
* If it's the MicroProfile Config API that is moving to Jakarta, my original concern is valid. This means that everytime that an API move between these communities it will cause a change, not only internally for other MicroProfile APIs,
but more importantly our uses.
We have this one chance that our users needs to change package names anyway due to javax, we should make sure we do this correctly.
Either MicroProfile needs to become a sub brand of Jakara and also make the change from org.eclipse.* to Jakara now (so we still only effect users once) or we need to find a brand (and org - so my initial org.eclipse suggestion is bad)
namespace to be used by both (and future) communities.
This is what we had with javax.
On 2019-09-26 11:24 a.m., Thomas Andraschko wrote:
IMO independent of MicroProfile or any other possible API which will be a part of Jakarta in the future, all specs in Jakarta needs the same "jakarta" namespace.
AFAIK, that is also the position of the Jakarta EE Specification Committee. I don't believe this is in any way a controversial statement. So just as Config expected to switch to the
javax namespace when it was under the JCP, it should expect to switch to the
jakarta namespace if it re-hosted there.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
