Jakarta EE Platform Call

Date: 2025-10-28

Present:

• Jared Anderson (IBM)
• Kyle Aure (IBM)
• James Perkins (IBM)
• Tom Watson (IBM)
• Ivar Grimstad (Eclipse Foundation)
• César Hernández (Tomitribe)
• Ed Bratt (Oracle)

Top of mind for Jared, James

• OSSRH update
  • Ivar talked with Sebastian. He is working on the new plugin. A new Nexus 3 is set up. Ivar is requesting to have it complete by the end of November.
• Next Jakarta Futures call
  • Our next scheduled Jakarta EE Future Directions meeting is scheduled for Thursday, October 30th, 2025 at 12:00 noon EDT.
  • Mary Grygleski will present some interesting ideas on Jakarta EE and AI. (delayed from last week)
• Platform and TCK project combination status
  • The EMO issue has the latest details
  • I am concerned about the TCK CI project being removed / archived. Seems we need to move over to the platform one and transfer all the jobs over there.
  • https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6746 is being done on October 30 that may affect things.

Jakarta EE 12

• https://github.com/orgs/jakartaee/projects/20/views/1 has been updated to M2 and M1 issues that were not done for M1 were updated to M2. Need to make new M2 issues for the other projects
  • Tasks to consider for M2
    • TCK lazy consensus policy per component
    • TCK issue template
    • Jenkins job publication documented in wiki / github pages
  • M2 date: Dec 9
• MP and Jakarta status
  • Emily is thinking to start a ballot in the near future about namespace
  • There have been discussions related to implementation projects being part of the working group and those to be in a separate space than Jakarta
    • https://www.eclipse.org/lists/jakarta.ee-community/msg03345.html
    • https://projects.eclipse.org/projects/ee4j has both specification and implementation projects under it
    • If implementations were moved to a separate space, would that affect the schedule for EE 12?
    • Would like to have opinion from the platform team since our opinion has a lot of weight
    • Would be nice to have more diversity of implementations for the release ballots
    • In order to release a specification, an implementation is required. So API and implementation can be pretty closely tied to each other