Description:
Per section 13.3 of the EE 10 specification, "there is no requirement around testing of JPMS in API jar signature tests or TCKs." However, there is a test in this TCK (and in truth, the entire automation of this TCK) that is doing exactly that.
Open Liberty does not provide API jars containing a module-info.class and as such is unable to run this TCK as it is currently written. Attempts to do so fail with the following:
[javatest.batch] java.lang.module.FindException: Unable to derive module descriptor for /jakarta/vi/wlp/dev/api/spec/io.openliberty.jakarta.activation.2.1_1.0.70.jar
[javatest.batch] Caused by: java.lang.IllegalArgumentException: io.openliberty.jakarta.activation.2.1.1.0.70: Invalid module name: '2' is not a Java identifier
[javatest.batch] Java Result: 1
If the automation is updated to not require JPMS in the API jar (by removing the module stuff from lines 191 & 192 in build.xml), then the UnnamedModule_Test still fails since it is explicitly testing that the API jar is on the modulepath.
Challenged Tests: build.xml javasoft.sqe.tests.jakarta.activation.Module.UnnamedModule_Test
TCK Version: Jakarta Activation 2.1.0
Tested Implementation: Open Liberty
Description: Per section 13.3 of the EE 10 specification, "there is no requirement around testing of JPMS in API jar signature tests or TCKs." However, there is a test in this TCK (and in truth, the entire automation of this TCK) that is doing exactly that.
Open Liberty does not provide API jars containing a module-info.class and as such is unable to run this TCK as it is currently written. Attempts to do so fail with the following:
If the automation is updated to not require JPMS in the API jar (by removing the module stuff from lines 191 & 192 in build.xml), then the UnnamedModule_Test still fails since it is explicitly testing that the API jar is on the modulepath.