Hi Steve,
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.
Werner
Hi Hussain,
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.
Steve
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Hussain.NM@xxxxxxxxxxxxx
Sent: 06 July 2020 14:09
To: jakartaee-platform-dev@xxxxxxxxxxx
Subject: Re: [jakartaee-platform-dev] Fair rules for"optional" TCKcompliance tests
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.
Thanks
Hussain
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.
Werner
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.
Steve
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.
While the wording in the EFSP seems a little unfortunate and strange or legal-phrased, most other places to improve or change things like the requirements to remove or make Features optional are in the Platform Specification of Jakarta EE anyway.
Werner
On 2020-07-02 7:05 p.m., Ed Bratt wrote:
I'd use 'requirements' instead of 'non-optional elements' but that's just me.
Since this is a language alteration to the EFSP, we'll eventually need to move this to the Spec. committee and then, I think we'll need some discussion at an even broader level.
The EFSP is now controlled by the Eclipse Foundation Board of Directors. A super-majority vote of the Board is required to change it. This puts it on par with the Eclipse Development Process.
There are also now multiple groups using the EFSP (Sparkplug, and soon AsciiDoc). They are certainly smaller and less complex than Jakarta EE, but their interests need to be respected when making any modifications.
Just wanted to make it clear that modifying the EFSP is now a more complex task than it was back in 2018 when it was being primarily formulated for the Jakarta EE Working Group.
Again, I don't think this needs to derail EE 9, but maybe I'm in the minority.
-- Ed
On 7/2/2020 3:33 PM, David Blevins wrote:
The EFSP states this for Compatible Implemention:
A Compatible Implementation must fully implement all non-optional elements of a Specification Version, must not extend the API (no supersetting), and must fulfill all the requirements of the corresponding TCK. A Specification Version must identify at least one Compatible Implementation under an Open Source License that implements all optional elements of the Specification and fulfills the requirements of all elements (including optional elements) of the TCK.
So, depending on the interpretation of the second sentence, the optional elements could be satisfied by one or more Compatible Impls. Regardless, it states that a Specification Version (ie. Jakarta EE 9) has to provide one or more CIs that demonstrate all Required and Optional aspects of the spec.
Right, we need something that is not open to interpretation. I am fairly confident that there were at least some of us who interpreted that strongly and literally as "a single implementation must exist that itself passes all optional and required aspects of the spec" and that after this point others could be free to implement the optional parts they chose.
If we want to allow a TCK's optional parts to be proven by a mix of implementations who, in aggregate, satisfy all the required and optional aspects of the spec then we should update the EFSP or JESP so no other interpretation is possible.
A Compatible Implementation must fully implement all non-optional elements of a Specification Version, must not extend the API (no supersetting), and must fulfill all the requirements of the corresponding TCK. A Specification Version must identify one or more Compatible Implementations under an Open Source License that, in aggregate, implement all optional elements of the Specification and fulfill the requirements of all elements (including optional elements) of the TCK.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
+1.613.220.3223 (m)
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Thanks
Emily
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.
