|Re: [jakartaee-platform-dev] Fairrules for"optional" TCKcompliance tests|
Thanks for the clarification. I recall we heard last week that Glassfish was required to build most TCKs at the very least, so unless that changed over time a lot we may have to consider Glassfish as the "de facto RI" even though an RI does not exist in Jakarta EE or the EFSP any more.
If there was no interest or ability to maintain Glassfish that way, then we might cross that bridge to also change the EFSP, but we can do that either working on Jakarta EE 10 or beyond.
What you write is correct but missed one last vital point from the EFSP see below (emphasis is mine).
“The Specification Team must provide evidence that cited Compatible Implementations fulfill all requirements of the TCK and that at least one Compatible Implementation implements all optional aspects.”
AFAIK only GlassFish currently implements all optional aspects of Jakarta EE 9. Therefore the Jakarta EE 9 release is dependent on GlassFish being the first amongst equals Compatible Implementation. The fix is to remove Optional parts in Jakarta EE 10 that nobody is prepared to support in their implementations OR accept that GlassFish is “special” and resource it appropriately.
I agree with Werner on no changes are needed in current wordings at both Process and Platform level. A spec can be marked as optional in platform/profile even when introducing a new feature and need not be only for the purpose of removal.
In the current Jakarta EE 9 platform, the XML Web Services specification is re-introduced as optional into the platform to fill in the gap left by removal of API from JDK. A vendor might choose not to implement this feature in Jakarta namespace and still maintain the javax version of implementation but can get certified as Jakarta EE 9 compatible.
Say NoSQL or MVC is added to the platform in Jakarta EE 10 as optional, it gives the vendor a choice to implement immediately or over a period of time based on user feedback.
Since the original discussion is on Glassfish having a disadvantage of implementing every optional element of the platform, I would like to point out that we no longer need to treat Glassfish as the reference implementation. As Ed pointed out earlier this restriction is due to how the TCK is implemented around GlassFish as RI. We as community should look at improving and innovating in this area which will allow any vendor implementation to act as Compatible Implementation for testing the TCK.
Today, Glassfish is the de facto implementation for Jakarta EE 9, maybe OpenLiberty could be for 10, WildFly for 11. What I am implying here is not an abandonment of Glassfish, but more towards other implementations completing it first (helps in finalizing a spec if a compatible implementation is ready) before Glassfish and later Glassfish can be certified against the first compatible implementation.
I don’t think the EFSP has to be changed either. The wording may be hard to understand not just by simple guys, but when turning a feature optional or even removing is concerned we should be able to make all changes in the spec that help formalize this.
Being a simple guy and following the mantra “If you can’t kick it it doesn’t exist”. I suggest that when planning Jakarta EE 10 if no member of the working group plans to implement a feature/specification that we would like to declare optional we simply remove it from the platform spec. That way there is no change required to the EFSP.
If somebody would like to implement it later then I suggest the specification moves or feature becomes standalone with a release cadence decoupled from the overall platform spec.
Note that if there is a single implementation that wishes to support an Optional specification and and wants to retain it in the overall platform specification then they have to agree to be on the critical path for delivery.
By the way, if we go ahead to make the spec change. I will suggest not to require a compatible implementation to implement Optional features. I think what David suggested to require implementations in aggregation implement all optional features has a few issues:
1. An optional feature might not be covered by any implementations. What do we do with it?
2. This might delay the spec release as it has to wait for a few implementations to cover all optional features. There will be some uncertainty.
3. If there is integration among optional features, these will be untested if we spread the optional features among multiple implementations.
I think simply not forcing implementation implements optional features makes sense and we then remove the optional features in the future releases.
On Mon, Jul 6, 2020 at 11:15 AM Werner Keil <werner.keil@xxxxxxx> wrote:
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.
Back to the top