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)
