| that’s a good point on the versioning Edwin, As Payara team, we’ve been doing that kind of versioning for quite some time and it really eases the whole process of doing releases with fixes and such. A codename could also provide a nice indicator for the release wagon as well.
I am also reluctant on gradual renaming and more into a big bang where we change the whole namespace to jakarta for packages, configurations, environment variables and etc. This would definitely provide less ambiguity for users who would want to use the brand new release.
As Josh mentioned, I also think that MicroProfile will make sense as a "profile" of Jakarta EE. There is a good deal of vendors providing solid APIs on metrics, healthcheck & such and those would be more visible under the umbrella of Jakarta EE.
Mert.
Hey Ryan,
I would like to share my thoughts on this matter as well.
As far as my information goes, initially we aimed to release Jakarta EE 8 as a Java EE 8 as-is compatible platform on the specification level. When this thought was brought into existence, the javax renaming discussion did not exist yet. So as of today, we could initially release Jakarta EE 8 compatible with Java EE 8, but with the implementations and specifications rebranded/renamed form javax.* to jakarta.*. This is likely to break back-wards compatibility, but on a code level, not on a functional level.
Therefore I personally prefer the big-bang renaming approach since that would provide the most solid base to start off with Jakarta EE. Advantages of this approach are that Jakarta EE is immediately no longer tied to Oracle copyrights and can therefore sail on it's own as a standalone platform, just like any other Java-based enterprise platform that is not owned by Oracle. This also means that it is a contained release that only requires extra work ONCE, which we can regulate with release notes, migration guides or any other form of support. Since the renaming needs to be done anyway, why not just do it as soon as possible, in a contained fashion?
I feel that if we progress gradually with the renaming, we keep taking into account what to rebrand or not with every evolutionary step of Jakarta EE. I think this approach will generate complexity on several levels, for example how the application servers are going to support this hybrid situation and how new specifications are going to handle this. This can slow down the evolution the Jakarta EE platform, a situation that is preferrably to be avoided if we want to adhere to the Eclipse Foundation's vision for evolving Jakarta EE.
Hope this helps to get to the collective decision on how to progress forward.
PS: Another thing that is on my mind is the naming convention for Jakarta EE. Does that necessarily need to be 8, 9, 10 etc? I feel that this can provide a psychological barrier for "increasing the number" that might feel as a big thing. What if we would adopt a naming convention like <year>.<release> (19.0, 19.1, 20.0 .20.1 etc), would that benefit the evolution of platform? This should provide a more intuitive release convention when we want to release Jakarta EE more often on a steady rythm like MicroProfile. Is that something that we would want to explore in this discussion, take into a separate thread or just ignore and continue with the current convention?
Kind regards,
Edwin Derks
As part of the Java EE Guardians, I agree with the statement sent out. I would like to see a big-bang change for the new naming convention to avoid confusion and make releases faster. I think any decision made to speed up the development process benefits everyone in the long run.
Regards, Wesley
Hi Ryan,
here is my opinion concerning the Java EE transition to Jakarta EE:
- javax* should be replaced by jakarta* at a one-time, immediate
transition!
Get rid of old things and show the community that a new platform
is rising (I know that technical this is not so easy as it
sounds)
- Jakarta EE 9 should contain the core components (EJB, JSF,
Servlet, Jax-Rs, CDI) and made it available sooner
We do not need to support backward compatibility in this
situation. Everyone who need to ran a legacy application can use
one of the available Java EE Application servers.
- Jakarta EE should include the Eclipse Microprofile APIs :
Config, Metrics, Health and fault-tolerance in its core.
In long-term Microprofile should become part of Jakarta EE.
For now most Open Application Servers (OpenLiberty, Payara,
Wildfly) already support Microprofile and so if Jkarata EE 9
does not include Microprofile in its core spec, this is not the
biggest problem
===
Ralph
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
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
