Jakarta EE Platform Call

Date: 2020-09-29

Present:

• Ivar Grimstad (Eclipse Foundation)
• Scott Marlow (Red Hat)
• Andy McCright (IBM)
• BJ Hargrave (IBM)
• Kevin Sutter (IBM)
• Paul Nicolucci (IBM)
• Tanja Obradovic (Eclipse Foundation)
• Cesar Hernandez (Tomitribe)
• Jean-Louis Monteiro (Tomitribe)
• Ed Bratt (Oracle)
• Werner Keil (Individual)
• Kenji Kazumura (Fujitsu)
• Emily Jiang (IBM)

Agenda and Minutes

Housekeeping with the zoom call

Leave the public zoom coordinates in our Agenda header.
This approach enables a “waiting room” for participants. Can add domains to automatically allow in but not individual email addresses. At this point, we do not want to enable a password for this meeting.

No Platform call next week (pmc call occurs at the same time)

All specifications have a PR for Jakarta EE 9 now!

Platform Specification (Kevin is driving)

• Web Profile and Managed Beans specs are in good shape
• Corba/IIOP removal (David is working on this)
  • https://github.com/eclipse-ee4j/jakartaee-platform/issues/220
  • Does this removal affect the TCK assertions? - Scott Marlow?
    • TCK assertions
  • [Marlow] The RMI-IIOP/Corba tests are still in the Platform TCK, they are marked optional tests that are not run by default.
    • What does it mean to keep the assertion ids for these test?
    • What does it mean that these tests are in, is RMI-IIOP/Corba technologies optional or removed from the Platform spec?
  • Should we remove these RMI-IIOP/Corba tests instead?
    • We should of created a separate TCK for these tests
    • By default, if we keep the tests for RMI-IIOP/Corba there will be confusion.
    • We could delete or exclude the RMI-IIOP/Corba tests.
      • [Marlow] Reach out to David and get his input on removing versus excluding the RMI-IIOP/Corba tests.
      • We should try to be consistent on how we handle pruning/removal of technologies and their tests.
        • This process should be documented on Platform TCK project.
        • We should document what we did with regard to removing tests.
  • Lack of module names (document our approach for jakarta ee 9)
  • Compatibility section (based on input from Will and Dan (steering committee))
  • Jakarta EE 9.1 release (uncommitted + just mentioning ideas)
    • Jakarta EE 9 requires Java SE 8 for compatibility
    • Something beyond Jakarta EE 9 (9.1, 10, …) will allow additional Java SE’s beyond 8

Jakarta EE 10 (recurring agenda item)

• Platform Guide
  • Ivar will set up a Google Doc where can start working on this
• [WK] JDK version (range)?