TCK has a defined flag (xml_binding) to demarcate the tests. (Scott Marlow)
Is there still an issue with indirectly referencing this Link class (the one that has the dependency on jaxb) and somebody might end up trying to load the jaxb classes? Maybe this just gets back to “user beware” of the Link class? (Scott and Andy)
Andy will verify the javadoc is sufficiently updated for the Link and Adapter classes.
Andy checked on the loading of the Link class and the ripple effect to the inner classes. It does not ripple, meaning that the javadoc comments on the Jaxb* inner classes are the appropriate place for them.
Andy checked the Specification for optional jaxb dependency and it is here: https://github.com/eclipse-ee4j/jaxrs-api/pull/854/files . Also, Ed brought up other references in the Spec related to Corba and IIOP.
TCK team doesn’t have the cycles to test all permutations of the various optional flags (across all components). Looking for assistance from other teams and other implementations.
Write PRs and/or Issues for items that still need changing.
Issues exist for the removal of Corba/IIOP (David Blevins volunteered for this item). Also, an issue exists for the new/updated Backward Compatibility section.
Web Profile and Managed Beans specs are much simpler and are probably very close. But, reviewing these would also be appreciated.
Platform TCK user guide- also needs a thorough review.
Module naming exercise should be “done” according to Werner.
Werner will post to Web Socket PR when he has completed the final verification.
Renaming of “master” branch to “main” (or whatever is the proper terminology).
Could be a global change to “main” across all github repositories?
Will be up to each team at this point. Nothing is required for Jakarta EE 9.
Jakarta EE 10
Need a replacement Kevin for Jakarta EE 10, to gather thoughts and direction
This will be the first Jakarta release with new features actually being added
Creating a release plan for EE 10 that involves going through what to include and what to leave out, so that is related to what we did for EE9 in the past.
Platform team agenda can include EE 10 item to get the conversation going.
Do we need a “Platform Guide” to help with guiding the component specifications going forward? A means of catching inconsistencies that are accidentally included in future component specs.
Platform TCK going forward
End goal (beyond Jakarta EE 9) is to separate the various Platform TCKs into their respective components (ie. Servlet, EJB, etc). What will be the requirements of these component TCKs so that they can still be pulled into the “platform TCK”?