Jakarta EE Platform Call

Date: 2020-09-22

Present:

• Kevin Sutter (IBM)
• Andy McCright (IBM)
• Ivar Grimstad (Eclipse Foundation)
• Jonathan Gallimore (Tomitribe)
• Jean-Louis Monteiro (Tomitribe)
• Dmitry Kornilov (Oracle)
• Ed Bratt (Oracle)
• Emily Jiang (IBM)
• Scott Marlow (Red Hat)
• Werner Keil (Individual)
• Tom Jenkinson (Red Hat)

Apologies

• Steve Millidge (Payara)

Agenda

[KWS] XML Binding (jaxb) is marked as an optional specification for Jakarta EE 9.

JAX-RS still has (had) a dependency on jaxb and it was causing issues with testing. Here are the actions taken so far. Is there anything else?

• Modify pom and module-info to indicate that the jaxb dependency is optional. (Andy McCright) https://github.com/eclipse-ee4j/jaxrs-api/pull/908
• Does the javadoc for this Link class need to be updated to better explain this optional dependency on jaxb? (Andy)
  • https://deploy-preview-260–jakartaee-specifications.netlify.app/specifications/restful-ws/3.0/apidocs/jakarta/ws/rs/core/link
• 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)

• Minutes:
  • 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.
    • https://www.eclipse.org/projects/efsp/#efsp-compatible
    • [Marlow] Note Jersey includes jakarta.xml.bind classes (thanks Alwin for checking!)

[KWS] Need three more draft Specification PRs for Jakarta EE 9

• https://github.com/orgs/eclipse-ee4j/projects/17#column-9442495
• JSP (Pages), JSTL (Tag Library), JSF (Faces)

Platform Spec needs more reviewing.

• 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”?