[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec] Issue for call tomorrow
|
The TCK cannot be an RC as it is part of the specification commit project PR that is being balloted on for final ratification. At that point there needs to be a staged final API artifact, specifications, java doc, and TCK. The compatibility request is verified against the final candidate TCK referenced in the PR. If the ratification ballot passes, the staged TCK is promoted to the final TCK without modification. All that process does is add the signing signatures of the specification committee.
+1 on clarifying this.
For rectifying a spec, the viable solution is to use release candidates for both APIs and TCKs to avoid chicken egg situations.
It has been a requirement that the TCK used for certification was the proposed final TCK, but not the APIs.
Based on what I said above, TCKs used for ratifying a spec can be a RC as well. This will certainly help with the specs that contain both APIs and TCKs.
Thanks
Emily
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.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jan 25, 2022, at 9:28 AM, Scott Stark <starksm64@xxxxxxxxx> wrote:
>
> An issue that came up during the platform call was what are the requirements for the compatible implementation that is used to ratify a specification. A specification team had decided that they could not produce an RC that could be used for such a ratification based on their interpretation of the following two document statements:
>
> • According to https://www.eclipse.org/projects/handbook/#specifications-implementations “Compatible Implementations may only claim compatibility with a final specification. ... No claims regarding compatibility may be made for an implementation milestone build or unratified specification version."
> • https://github.com/jakartaee/specifications/blob/master/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md, which states, "For a Release Review, a summary that a Compatible Implementation is complete, passes the TCK, and that the TCK includes sufficient coverage of the specification."
>
> If I look really pedantically at these two statements, maybe I could read that only final APIs can be used by a compatible implementation, but this is also ignoring other discussions we have had about the special nature of the compatible implementation used to ratify a specification.
>
> We need to make a clear statement about the requirements for the initial compatible implement(s) used to ratify a specification as well as any additional constraints on post ratification compatible implementation claims.
>
> It has been common practice in EE and MP to use ratifying compatible implementations that do depend on release candidate APIs. It has been a requirement that the TCK used for certification was the proposed final TCK, but not the APIs. By virtue of passing the TCK signature tests, whatever API versions the compatible implementation used, they have been validated as compatible as determined by the final TCK. This should be a sufficient validation of the compatible implementation.
>
> Let's discuss tomorrow.
>
> _______________________________________________
> jakarta.ee-spec mailing list
> jakarta.ee-spec@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
