That’s good to hear, because for several TCKs there could be a "Chicken and Egg" problem about what implementations to use for at least compiling them.
I trust it won’t be a big problem building the TCK with Payara instead of Glassfish, but what about the others and can e.g. the CDI and Bean Validation or the Batch TCK be compiled using another compatible implementation say JEUS or Primeton as of now?
EE9 is not a problem we volunteered along with others to get GlassFish over the line for EE9.
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 06 July 2020 16:12
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Fair rules for"optional" TCKcompliance tests
Exactly. Hence, unless some sponsor is explicitly stepping up to bring the EE9 specs, their TCKs and an implementation across the finish line, those specs need to be dropped from the EE9 platform.
My summary reading of the EFSP wrt optional is;
- Jakarta EE Platform specification is a specification under the EFSP and therefore specification rules apply.
- A specification can have optional parts which must be mutually compatible I.e. you can implement all optional parts
- All optional parts must be covered by the TCK
- A specific compatible implementation doesn’t have to implement optional parts.
- A specification version must identify at least one compatible implementation that does implement all optional parts at release review.
Therefore by definition if the platform specification has optional parts that nobody wants to create a compatible implementation for then that specification version can not be released.
So as in my previous email the solution in the Jakarta EE 10 timeframe is to aggressively remove all optional parts of the platform that nobody is prepared to implement.