I'm not sure this is the right place for this discussion. Please
let me know if you think this should be moved to the platform-dev
mailing list or elsewhere.
At the end of the Compatibility
Certification Request for Open Liberty, it lists these issues:
Relevant challenges & resolution:
Signaturetest - Implemented work around to allow testing of
remaining packages.
eclipse-ee4j/faces-api#1474
JSONB - Excluded tests.
eclipse-ee4j/jsonb-api#180
DI TCK requires SeContainer
javax-inject/javax-inject#39
Since we've committed that the Jakarta EE 8 TCKs will be identical
to the Java EE 8 TCKs, we can't fix any of these issues in the TCKs
for the Jakarta EE 8 release. We can consider these as TCK
challenges after the Jakarta EE 8 release is approved, and release
updated TCKs to address the challenges per our process, soon after
Jakarta EE 8.
Do you agree?
The first item in the list above is problematic...
It's a signature test issue. For Java EE, we would release an
alternate signature test, to allow products to pass either the
original or updated signature test. For Jakarta EE we decide we
would not create alternate tests. We can't exclude the signature
test. If we update the signature test, products that have passed
the existing Jakarta EE 8 TCKs, and all Java EE 8 products, will
fail the updated test and thus won't be Jakarta EE 8 compatible.
How would you like to handle such a case?
For the second item in the list above, it seems that we've agreed to
exclude the challenged tests. An updated version of the JSONB TCK
can be produced soon after Jakarta EE 8. We can use this as a test
case for how to approve an update to a TCK without a corresponding
spec update.
Can someone describe the process for approving a TCK update without
a corresponding spec update?
The third item in the list above was filed only recently and hasn't
been evaluated. If I understand it correctly, the Dependency
Injection TCK assumes that you have a "standalone" implementation of
Dependency Injection, and can thus test it outside of a Jakarta EE
container. That's clearly not a requirement of Jakarta EE, nor of
Java EE. I assume this challenge was filed for Open Liberty because
it doesn't not include a Dependency Injection implementation that
can be used outside of the Jakarta EE containers.
WebSphere Liberty is Java EE 8 compatible, how did it run the
Dependency Injection TCK? Is Open Liberty using a different
Dependency Injection implementation?
Converting the Dependency Injection TCK to be able to work inside a
Jakarta EE container is likely a non-trivial task. Excluding all of
the Dependency Injection tests seems unacceptable.
How would you recommend that we address this test challenge?
|