There's been some discussion in the last week on a PR against the Jakarta EE TCK process guide[1] and on today's platform call[2] that needs discussion on this list.
The background is that last year there was a 'Requirements on standalone TCKs'
specification committee issue[3] that resulted in an update to the TCK process guide[4]. I think I can fairly correctly characterize the key motivation there as a (valid IMHO) desire to ensure that as new 'standalone' TCKs are created we don't lose the ability to test that EE component impls work correctly in an actual EE environment.
We are coming up on release deadlines for various component specs, but I don't think the precise implications of the TCK process change are understood (for example, see the discussion at [5]). So my goal here is 1) to get more clarity, 2) to increase awareness of these requirements and 3) to work through any implications for completing the EE 11 release.
I'll frame all this in terms of questions. Some I'm pretty sure I know the answer, but maybe I'm wrong, or maybe others are less sure. Note that I'm going to refer a fair bit to things discussed in the links below, particularly the change included in [4].
1) What is a 'standalone TCK'?
This is a term for an individual specification's TCK that can be executed independent of the larger platform or profile TCK. This does not just mean a TCK for a 'standalone specification', i.e. a Jakarta spec like Jakarta MVC that is not part of any platform or profile.
I like Emily Jiang's use of 'individual specification TCK' in the [4] change, as it avoids the ambiguous meaning of 'standalone'.
2) Is this relevant to TCK service releases?
It's been clearly agreed that this is only relevant for TCKs that are producing updates for major or minor spec releases. Service releases are unaffected; service releases are not allowed to make these kinds of changes.
3) What are Type 1 tests?
I believe this refers to tests of things like 'CDI in Java SE'[6] -- that is, cases where specs have requirements that are only relevant when not running in an EE container. What matters is the type of spec requirement, not how a test has historically been executed.
This is a relatively small subset of all EE TCK tests.
4) How should Type 3 tests work?
My expectation is most tests are Type 3 tests.
The requirements in [4] state that an individual spec must provide a mechanism to run Type 3 tests within a platform/profile, but also must make it possible to run them outside of one. (I assume the latter is to avoid a circular dependency problem where a spec can't release because there is no platform/profile to test against, because the spec hasn't been released...)
Do we have any advice/best practices for how to do this? Anything we can extract from CDI, which handles this?
5) What about existing individual specification TCKs?
We've long had individual specification TCKs, and I'm sure some of what they include is Type 2 or 3 tests. Are we requiring that specs with those kinds of TCKs that are doing major/minor updates for EE 11 update those existing tests so they can run in a platform/profile impl?
6) What new individual specification TCKs are we expecting?
I know we are refactoring the platform tck to try and move toward individual specification TCKs, but I haven't followed the details on where this is going.
7) Are the spec groups producing major/minor releases aware of these requirements? Where do things stand?
My guess is in most cases the answer to the first question is 'No'.
-- Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
