To record our decisions, hopefully matching what will be in the
minutes...
Bill Shannon wrote on 9/3/19 2:26 PM:
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?
I do not believe there was agreement that the Jakarta EE 8 TCKS must
be identical to the Java EE 8 TCKs. The first item below
allows them to be effectively different in that they have different
acceptance criteria.
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?
We decided that we would accept as "compatible" an implementation
that failed the Jakarta Server Faces signature test in exactly the
ways described above.
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?
We agreed to provide an updated TCK with the additional exclude list
entries.
It's still unclear to me what the process is for approving that
updated TCK.
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?
We decided that it would be best if Open Liberty simply ran the
Dependency Injection TCK on the Weld implementation that it is
using, and if that was possible the test challenge would be
withdrawn.
|
