[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance tests
|
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.
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.
_______________________________________________
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