Re: [jakarta.ee-spec] [External] : Re: [jakartaee-platform-dev] Issue fo

[Scott Stark <starksm64@xxxxxxxxx>]

Maven artifacts are only one problem. The bigger problem is that TCKs are generally a bundle that includes the tests, user guide and example of integration with the implementation under test. That is not a generally useful artifact to push to maven for automation. The tests portion and associated resources, certainly, but the rest?

On Jan 26, 2022 at 10:33:18 AM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:

i apologize, I have not digested the very long dependency example. I will get to that. but first I just wanted to inject what we have done in EE 9 (which didn't push final TCKs to Maven):

The proposed final TCK was published to a download folder. Along with that publication a SHA-256 sum was generated.

That proposed final TCK was referenced in the final release ballot (in the PR comments) and also in the referenced CCR (one or more). The SHA-256 is also published as reference and it was routinely checked in the various supporting materials.

Once the ballot was approved that exact TCK was copied into the Spec. Committee controlled download directory and an authentication signature is generated. The SHA-256 is common from the "proposed-final" to the "final-final" copy and that verifies that the TCK that was used to verify the compatible implementation for release ballot is one and the same as the final TCK.

Once the ballot concludes that "proposed-final" TCK becomes "final." Since there is no change to the TCK, the compatible implementation need not re-check anything -- nothing changed in the TCK. Were any change to occur with the TCK, the process of certification would need to be done all over again.

TBH, I am unsure how this copy behavior can be replicated properly with Maven artifacts. Perhaps that is one source of the difficulties here?

-- Ed