[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jakarta.ee-spec] What are the allowed changes in point releases of TCKs?
|
There was a general belief that fixing buggy tests in a service release of a TCK was allowed during today's spec committee call, but if you read the current TCK process:
https://jakarta.ee/committees/specification/tckprocess/
One reading would be that a service release can only update the exclude list, and update tests for addressing bugs for newer Java SE versions.
We have a current challenge in the concurrency TCK that is seen in the web profile version of GlassFish:
The issue is that the TCK uses remote EJBs, a technology that is optional in the Full Platform, and not supported in the Web Profile. A proposed fix is to replace these in favor of local interfaces since the tests make no assertions about remote interfaces. The PR for that is here:
We have had a number of challenges to TCKs largely due to tests being moved out of the Platform TCK into separate projects with different test harnesses. The RESTful TCK also has a challenge related to the optional JAXB and either porting errors or misunderstanding of how exclusions/optionality are handled in the junit5 testing framework.
Several questions arise with these challenges and the current TCK process:
- Is the proposed change to the concurrency TCK allowed within the current TCK process?
- If not, a minor release would be required to actually update the tests rather than losing coverage via exclusion. Would this require a minor spec update and ballot? If so, that is way too much overhead to fix tests. If not, what is the procedure?
- Not all test frameworks have an externalized representation of excluded tests. Junit5 does not have a suite file format as far as I know. You can configure excluded tests via a surefire configuration, or a custom class that makes use of the @Suite and related annotations, but no common approach. Excluding tests could also require adding junit5 annotations to tests. Are such updates allowed because they are effectively updating the excludes list?
What Red Hat would favor is an approach that allows the specification project team to make whatever changes them deem appropriate to address a spec challenge.
