Emily-Jiang
commented
2 years ago Further comments for @JanWesterkamp-iJUG Additionally, following Ed's concerns I think we should wait for the results of the ongoing discussions in Jakarta EE which might affect us in MicroProfile too. Even when there are significant differences as we have one version and one namespace for all relevant artefacts (spec document, API, TCK) of a component spec and they all stored in Maven already.
The original message is here
Comments from @edbratt regarding the current TCK process:
Packaging requirements:
Jakarta EE is struggling with the requirement that forcing the ancillary (supporting documentation, guides, coverage, and assertion documents) into the TCK binary is problematic for publication to central repositories such as Maven central. We are currently working on an effort to update the packaging aspect of these requirements. MicroProfile may want to consider updates along these lines itself, or perhaps wait until after Jakarta EE determines what changes it will allow and then follow suit.
Test changes in Service Releases
The very final clause of the document (that service releases '... may have test changes...') might be considered for update in a future revision
In the past, we tried to adhere to the rule -- Once a test is formally adopted, it cannot change -- If the Spec. dev. team receives a challenge and it feels that a specific test must remain but the test must be altered, we allowed that an Alternative test could be provided in the TCK. If an alternative is offered the vendor could choose to run the original test, or the alternative test and they are considered equivalent for the purposes of compatibility verification. The goal was existing tests cannot be changed in anything less than a minor release. Successfully challenged tests may be excluded OR, they may remain and either the original or the alternative may be chosen by the vendor.
Alternative tests were rarely utilized. The decision to provide an alternative test or simply exclude that test would be at the discretion of the Spec. development group. Allowing a general assertion like this seems difficult to manage, in my opinion. I would discourage groups from attempting to change the TCK tests themselves in service releases.