[jakarta.ee-spec] Component TCK requirements

[Scott Stark <starksm64@xxxxxxxxx>]

This is the email I promised to follow up with during the discussion from today's platform call. Here are the key sections that outline the requirements for TCK deliverables as described in version 1.2 of https://jakarta.ee/committees/specification/tckprocess/

Under the Materials for a TCK Release section, one finds:

* Projects MUST produce the project licensed (EPL, Apache, etc.) version for distribution to Maven Central or other open source channels, usable for automated, non-official testing, and implementation. No compatibility claims can be made on the basis of this TCK.

* Projects MUST produce a final candidate binary that includes the EFTL license. The Jakarta EE Specification Committee will sign and promote project TCK binary for distribution via Eclipse infrastructure on final approval. This is the TCK binary usable for self-certification when one desires to make a claim of compatibility, allowing for the use of the Jakarta brands.

* Both TCK binaries MUST contain the following

** User guide outlining

*** Software requirements

*** Installation and configuration

*** How to run the tests

*** Where to file challenges

*** TCK specific rules not covered in this process guide

** Instructions describing how to run the compatible implementation(s) that are being used to validate the TCK

** A top-level README document pointing to each of the preceding documents

* Release available via a release on project GitHub releases page(or equivalent)

** Final releases under the EFTL MUST be hosted on download.eclipse.org

Under Ratifying a Final TCK one finds:

* Projects will submit the EFTL proposed final binary of the TCK for approval to the Specification Committee.

* The Specification Committee will vote to approve or reject the TCK binary.

* Approved binaries will be signed with the GPG key of the Jakarta Specification Committee, and then published on download.eclipse.org along with the digital signature of the SHA-256 hash of the final binary, and the SHA-256 hash of the binary as the fingerprint of the TCK.

* Consumers can use the GPG key of the Jakarta Specification Committee to verify the authenticity of that or any TCK binary.

Under Filing a Certification Request one finds:

Requests to be acknowledged as a certified implementation MUST be filed via the specification project’s issue tracker using the label certification and include the following information:

* Statement of Acceptance of the terms of the EFTL

* Product Name, Version and download URL (if applicable)

* Specification Name, Version and download URL

* TCK Version, digital SHA-256 fingerprint and download URL

* Implementation runtime Version(s) tested

* Public URL of TCK Results Summary

* Any Additional Specification Certification Requirements

* Java runtime used to run the implementation

* Summary of the information for the certification environment, operating system, cloud, …​

* A statement attesting that all TCK requirements have been met, including any compatibility rules

Given that context for requirements, it seems clear that a specification project needs to produce a single binary artifact with the required contents. This artifact also needs to include the non-open-source EFTL (https://www.eclipse.org/legal/tck.php) license.

It would seem the minimum a project could do would be to produce a dual licensed jar/zip file with the required contents and make it available via maven.

As Ed pointed out, I believe we asked the question of whether dual licensed TCK binaries would be acceptable to both Maven Central terms of use, and the Jakarta TCK process. The questions to Maven Central and the EF EMO would be:

1. Does a dual licensed binary with both open source and proprietary licenses meet the Maven Central terms of use?

2. Can such a binary be used to meet the Jakarta TCK process terms?

It would seem that the only way this could happen in the context of the Jakarta TCK process would be:

1. A specification project produces the TCK binary and releases it to the Jakarta staging repo. 

2. The final specification ratification PR references this staged artifact.

3. When the specification is ratified, the Specification Committee copies the artifact to the download.eclipse.org location along with the GPG signature and SHA-256 checksum.

As I read these requirements, anything else would require a change in the Jakarta TCK process, but if someone has an alternative they believe meets the requirements, please propose it. We will need to take a decision in the upcoming Feb 23 Specification Committee meeting.

Scott Stark (Red Hat)

EE10 release coordinator