Skip to main content

Jakarta EE Platform Call

Date: 2025-05-06
Present:

  • James Perkins (Red Hat)
  • Jan Westerkamp (iJUG)
  • Ed Burns (Microsoft)
  • Emily Jiang (IBM)
  • Ivar Grimstad (Eclipse Foundation)
  • Scott Marlow (Red Hat)
  • Cesar Hernandez (Tomitribe)
  • Petr Aubrecht (Payara)
  • Arjan Tijms (OmniFish)
  • Gurunandan Rao (Oracle)

Top of mind for Ed, Arjan, Jared

  • Recover from Eclipse outage
    • TCK aspects
      • https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6001
        • An initial plan was agreed upon between the TCK team and Eclipse IT.
        • Denis Roy’s email from Monday: “With the help of a third-party team of experts, we’ve been able to access the filesystem that contains all the CI instance information.”
          • Does this change the plan?
  • Tentative schedule thoughts
    • May 21 April 30 TCK complete
    • June 5 May 15 CCR created and mentor review started
    • June 9 May 19 start ballot (complete 7 to 14 days)
      • Given the email from Denis Roy, is it possible we can move these earlier? It is certainly safer to take the time. On the other hand, we certainly want to get it done and move on.

Jakarta EE 11

Jakarta EE 12

  • Plan review ballot status https://github.com/orgs/jakartaee/projects/17
  • Review where components specs are on the board
    • Still waiting on 4 components to create a release plan or decide on no release for EE 12
      • Mail (Lukas): Jorge Bescos Gascon provided the plan for EE 12
      • Activation (Lukas): Jorge Bescos Gascon provided the plan for EE 12
      • Interceptors (David Blevins): This likely will not pursue a new version for EE 12
      • Messaging (David Blevins): David declined to pursue a new version for EE 12.
        • Jan observed there is a need for a service release to address some important maintenance issues. This is not related to EE 12, but should be done as we work on EE 12.
  • Jakarta HTTP
  • MicroProfile moving to Jakarta update
    • Recap from MicroProfile project meeting 2025-04-28?
      • MicroProfile is working to establish consensus among themselves regarding their “red lines”.
      • These will inform the specific proposal.
      • Straw poll on the proposal.
      • Apply changes if necessary.
      • Share with Jakarta Steering Committee
      • Assess Jakarta Steering committee response.
      • Actual ballot among MicroProfile community.
      • Then this goes back to Jakarta to vote to accept this or not.
        • Arjan reminded us of the significant overlap on among the constituents voting on the MicroProfile side and the Jakarta side.
  • Administrative issues board https://github.com/orgs/jakartaee/projects/18
    • Specification-committee #74
      • TCK lazy consensus issue discussion for platform TCK component spec projects with tests that happen to reside uniquely in the platform TCK.
        • Reject the use of lazy consensus.
        • Platform project commits to accept or decline a challenge within 30 calendar days of the challenge being lodged.
        • Arjan observed that we should strive to make it so the set of tests in this bucket is empty. Let’s continue this work.
        • Notes: Three sets of tests:
          • 1. Tests that happen to reside in the platform TCK, but are effectively standalone tests. For example tags.
          • 2. Tests that are primarily about one particular component specification, but exercise functionality in multiple other component specifications.
          • 3. Tests that do not belong to any component specification.
      • TCK lazy consensus issue discussion for component specifications
        • Fact: it’s hard to define a one-size-fits all policy for this aspect.
        • Proposal: Include defining a TCK challenge timeline policy (which includes having or not having lazy consensus) as part of initial Jakarta EE 12 milestone.

Back to the top