Re: [jakarta.ee-spec] [External] : Re: Issue for call tomorrow

[Ed Bratt <ed.bratt@xxxxxxxxxx>]

One thing I would like to exclude is any requirement that a compatible 
implementation, used for release ballot, must be exactly build-able at 
any time in the future.

The compatible implementation used for release ballot must be 
open-source. We can require that the source be preserved (we kind of 
imply that the candidate be "released" in some manner but I don't 
believe we are detailed in that requirement and I don't think we need to 
be). In my opinion, it should not be an obligation of a prospective 
ballot CI to provide, nor support building of that release at any time 
in the future. (If a prospective ballot CI wants to offer this -- great 
-- it simply is not an obligation.)

One issue that frequently comes up in the product release end-game is 
the need to update pom file GAVs from <package>.bxx.yy (bxx or rcx or 
whatever) to <package>.yy. Most commonly this is done when all the 
various components have finalized their releases and the project team 
does a sweep that moves all the prospective-final GAVs to their 
final-final GAVs. In our current release methodology, an early ballot CI 
may need to wait for quite some time before all the dependencies which 
were used to build and validate /that/ implementation become final in 
themselves.

If we require source preservation or tagging or whatever -- I would 
propose "for reference only" be the totality of what is required. Pom 
file changes (like I've described above) should not invalidate the 
prospective CI. Nor, would I say that inclusion of components that are, 
themselves still evolving, be disallowed.

The CI must pass the TCK. The TCK includes tests and instructions. The 
Specification Team and the CI implementer assert that all the tests 
cover what they should cover (behavior and signatures). That's all there is.

Even if we wind up not agreeing to this point, we should clarify this 
(whatever the prospective CI requirements are) so it's clear to our 
community.

-- Ed

On 1/25/2022 12:56 PM, David Blevins wrote:
> Agree.  If the signature tests pass, all is fine and the vendor is allowed to use their own API jars.  In some cases those API jars are implementations: Faces, Activation, Mail, etc.  There are other situations like JACC where the API jar can't really be considered an implementation, but there is definitely significant code there.
>
> We'd likely want to document those requirements in the JESP as the EFSP is what currently holds the open source requirement.
>
> We may need to add some clarification on the API jars produced by specification projects as people are increasingly referring to them as "the official" jars, implying 1) all other jars are not official or lesser and 2) they must be used by the compatible implementation used for ratification.  Neither is the case.  We need some explicit text that says we have no concept of "the official" jars and any jars that pass the TCK and signature tests are equivalent.
>
> For Jakarta EE 8 our compatible implementation was a pre-Eclipse version of GlassFish that did not ship the jars produced by the Specification Projects.  We did do some work to ensure the Specification Project-produced jars could pass a TCK run.  If we have thoughts that this should or does not need to happen again if a compatible implementation does not use the Specification Project-produced jars, we should write that down too.