Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance te

[Emily Jiang <emijiang6@xxxxxxxxxxxxxx>]

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.

I have a minor question about the modification. Let's look at this scenario:

Say we have optional features A, B, C

In Jakarta EE9, Open Liberty implements A and B. TomEE implements C.

In Jakarta EE 10, Open Liberty decides not to support B any more and no other runtime supports B. Should we remove B from the platform Spec? I don't think this is a valid reason to hold off the release because in aggregation we can't cover all optional elements. This is pretty much a natural route from optional to removal.

If we are in agreement, should this be documented somewhere?

Emily

 

On Thu, Jul 2, 2020 at 11:33 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

On Jul 2, 2020, at 3:15 PM, Kevin Sutter <sutter@xxxxxxxxxx> 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.

How about this?

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.

-David

_______________________________________________
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