| [jakartaee-spec-project-leads] TCK testing of Compatible Implementations for Jakarta EE 8 |
|
There's some confusion about what needs to be tested with the
Jakarta EE TCKs for Jakarta EE 8. Our current instructions
don't make this clear. I'll need to update those instructions, but
let me start by explaining it here... We're updating the APIs in order to update the javadocs. We need to release those updated API jar files in order to create the combined Jakarta EE API jar file. Since we're releasing those API jar files, we want some confirmation that they're correct. Running the TCK against those API jar files gives us that confidence. Those TCK results don't need to be saved or published since they don't correspond to a complete Compatible Implementation that will be released. Separately, we need a Compatible Implementation for every spec. That CI does NOT need to use the updated API jar file, although it may. The release review for each spec needs to point to the CI and the TCK. The CI needs to pass the TCK and those results need to be made available. For the platform, the CI will be Eclipse GlassFish 5.1, unchanged. We will test it with the Jakarta EE platform TCK and make those results available. For individual specs, there are several approaches: The CI can be updated to use the updated API jar file, and this updated CI can be tested with the TCK. In this case, the TCK testing combines the requirement for testing the API jar file with the requirement for testing the CI, and these TCK results would be saved and published. Only a few specs are expected to take this approach. The CI can be updated without using the updated API jar file, and this updated CI can be tested with the TCK. I don't know of any specs taking this approach. The CI that was released along with Eclipse GlassFish 5.1 can be used unchanged, and this pre-existing CI can be tested with the TCK. I expect this to be the most common approach. Specs with no standalone implementation and that use GlassFish as their implementation can continue to refer to Eclipse GlassFish 5.1, and can test it with the standalone TCK for the spec. For specs with no standalone TCK, they would use Eclipse GlassFish 5.1 as the CI and would test with the platform TCK using the subset of tests defined for that spec. This includes things like Jakarta Enterprise Beans. This table on the Java EE web site will give you an idea of which specs use GlassFish as their Compatible Implementation. To summarize, running the Jakarta EE TCK for a spec against the API jar file for the spec is necessary but not sufficient. The Jakarta EE TCK for a spec also needs to be run against the Compatible Implementation of that spec, which in many cases will be the existing Eclipse GlassFish 5.1 release. If you have a TCK job that uses a GlassFish zip file, many of you should just need to point that TCK job at the existing Eclipse GlassFish 5.1 zip file, and collect the TCK results for submission with your spec. Let me know if you have questions. |