issues/1813 Update TCK Process to unblock ballot release of EE 11 Specification ballots that have traditionally been done with Java SE style TCKs.

[scottmarlow]

See discussion on #1813.

If this change is made or a change like it, we should follow up to make a further change to cover Update TCK Process to specify that Jakarta EE Platform implementations only need to pass TCK tests that can be run against a Platform (e.g. EE containers) implementation to be considered Jakarta EE Platform compatible. This change might not really belong in the TCK Process guide as it is specific to Platform/Profile TCKs. I suggest that the https://github.com/jakartaee/platform-tck/tree/tckrefactor might be a better place to specify the requirement which does imply more work will be done for the Platform TCK to support running such tests (e.g. Core Profile 10 TCK already has an example of doing that).

CC @Emily-Jiang @lukasj

[netlify]

✅ Deploy Preview for jakartaee ready!

Name	Link
🔨 Latest commit	45b5b9f
🔍 Latest deploy log	https://app.netlify.com/sites/jakartaee/deploys/65cbb0a3b7d5b400089483a2
😎 Deploy Preview	https://deploy-preview-1852--jakartaee.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Emily-Jiang]

I disagree with this change. The reason to add the statement is to prevent from specs just having standalone tcks. I would rather the spec fixing the issues rather than pushing the releases out.

[bstansberry]

@scottmarlow @Emily-Jiang @lukasj @edburns

I think it would be good to have a discussion going through the implications of the existing text on the various specs as a way of better understanding what's meant by the text and how it will affect EE 11 and service releases.

I believe I understand what's intended by the existing text, but working through some concrete cases will give me more confidence that I really do. As a person primarily concerned with implementing the profiles and full platform I certainly appreciate the general thrust of wanting to ensure that relevant tests can run in an EE environment, particularly as we continue to work to move spec-specific tests out of the platform TCK.

I have no sense at all though of how much effort and time getting the various TCKs to comply with this will require, and since EE 11 is an phase where deadlines are imminent I think it would be good if we had more clarity around that.

[lukasj]

XML-Binding can be used as an example affected by current wording should it want to produce an update release. The TCK for this particular spec is and always has been SE based, unless I'm mistaken, and any, even simple, change there requires non-trivial effort. Simply re-running all tests within all possible existing vehicles (or profile/container combination if you wish) would lead to an insane number of hours required to validate vendor's EE runtime (likely more than a day) - I do not think that is a right way to go. Alternatively it could be said that XML-WS TCK is used to validate XML-B runtime, since it XML-WS spec is heavy user of XML-B, but XML-WS is just an optional part of the platform, so not every vendor has an option to use it.

As for implications on current service releases - given the service release is based on EE 10 artifacts, updated rules should not be applicable as the change in the process should not be retroactive.

[bstansberry]

As for implications on current service releases - given the service release is based on EE 10 artifacts, updated rules should not be applicable as the change in the process should not be retroactive.

Makes sense to me. TBH I'm not an EE process expert, so maybe this is already a clear rule. If not we should make it one, and if it is already a rule it's good to socialize it a bit to be sure others are aware.

XML Binding seems like the extreme case in terms of the implications of these requirements, so extreme that I can imagine just in the interest of expediency it ends up getting a permanent exemption. :) I'm just one voice on that though, and not a voting voice on any relevant committee. If service releases are not affected it gets at least a temporary exemption, as there's no major/minor release planned for EE 11.

But I'm sure there are other specs doing major/minor releases for EE 11 that will be affected.

[Emily-Jiang]

As for implications on current service releases - given the service release is based on EE 10 artifacts, updated rules should not be applicable as the change in the process should not be retroactive.

Yes, any service release is not affected by the new process.

Makes sense to me. TBH I'm not an EE process expert, so maybe this is already a clear rule. If not we should make it one, and if it is already a rule it's good to socialize it a bit to be sure others are aware.

XML Binding seems like the extreme case in terms of the implications of these requirements, so extreme that I can imagine just in the interest of expediency it ends up getting a permanent exemption. :) I'm just one voice on that though, and not a voting voice on any relevant committee. If service releases are not affected it gets at least a temporary exemption, as there's no major/minor release planned for EE 11.

But I'm sure there are other specs doing major/minor releases for EE 11 that will be affected.

This process will be in place for any TCK rework and new TCKs. For the XML Binding spec, we can look into the details and might need to make it exception. As a general guidance, we should design TCKs to be executed by Jakarta EE runtimes.