Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2025-09-16

Present:

  • Jared Anderson (IBM)
  • Kyle Aure (IBM)
  • Anand NK (IBM)
  • James Perkins (IBM)
  • Scott Marlow (IBM)
  • Brian Stansberry (IBM)
  • Reshmi Vijayan (IBM)
  • Tom Watson (IBM)
  • Cesar Hernández (Tomitribe)
  • Jan Westerkamp (iJUG)
  • Dmitry Kornilov (Oracle)
  • Arjan Tijms (OmniFish)
  • Otávio Santana

Top of mind for Jared, James

  • Ballot for combining Platform and TCK projects has started. Will complete on September 24 if not all committers have not voted before that. All positive votes thus far.
  • OSSRH update
    • Activation was able to publish a service release for 2.1 to maven. Guessing was not using staging to do it.
    • Parent POM experimental update has been merged to allow for playing with the new plugin, but we still have limitations with the current implementation. Discussions on slack about some alternatives happened last week as well.
      • There isn’t a snapshot yet of the parent pom. Someone needs to run a jenkins job in order to publish the snapshot for use by other projects.
    • The Release Engineering (RelEng) team has put out a latest status on OSSRH migration here. There is a lot of good information in that mail. The latest status is still being tracked in this issue.
  • First Jakarta EE 11 CCRs were created last week Friday. 30 previous EE release CCRs are still to be approved / reviewed.

Jakarta EE 12

  • Update from the Jakarta Query project

    • The currently 47-page spec covers:

      1. the basic type system defined in terms of structural typing
      2. a reasonably rigorous definition of the semantics of all the basic operations available in the query language
      3. the definition of the core language (lifted almost verbatim from the JDQL spec)

      We’re currently working on extending this to cover all the functionality of the extended language (i.e. JPQL) but that’s a rather large task and we only just started.

      We also need to revisit (3) and tie the definition of the language more carefully to the semantics defined in (2).

    • Jakarta Query 1.0-SNAPSHOT Specification Document
    • 8 issues remain to complete for Jakarta Query to be complete
    • Otavio is confident that it will be complete in the next 1 to 2 months
    • README at https://github.com/jakartaee/query also has been updated with some overview of the Query specification and the history of the query functions in the Jakarta ecosystem.
    • Two parts of the Jakarta specification – Core Query (Data and NoSQL) and Extended Query (Persistence) model
    • TCK / tests discussion happened last week as well.
      • Last week discussed possible abstract tests possibly
      • Each consumer would be required to provide TCK for it
      • Query could not ratify until one or all of dependent specs ratify?
      • Interceptors and annotations have similar issues where the TCK tests are not in their repositories, but are reliant on the consumers of the technologies
      • Would need to have a Data or NoSQL pass their query testing and Persistence pass its query testing in order to ratify Query to cover both the Core and Extended functions of the Query specification
  • NoSQL status
    • https://github.com/jakartaee/nosql/milestone/2 documents the current status
    • Driver is still being worked on, but not there yet
    • Driver will likely need to be there in order to be considered for the platform
    • Without driver support each vendor may do their own API and cause things not to be done in a standard way.
  • Data status
  • MicroProfile and Jakarta update
    • Status on Plan and discussion that Emily was supposed to initiate
    • Emily is not here today. Still be done. Been traveling.
    • Some of David Blevins concerns with the WG charter related to EE4J were discussed at the Steering Committee last week.
    • EE4J and Jakarta Github project separation has been happening – API in jakartaee organization and implementation in eclipse-ee4j organization
  • Debugging specification fate
    • Remove it from the platform since it isn’t used? Deprecated / marked for removal first?
    • Fold it into the Jakarta Pages specification?
    • There is only 1 test with Pages from a TCK perspective
    • It was intended to allow for debug for other languages, but never really happened and only has been used by pages.
    • It isn’t in its own repository in github. It is part of the pages repository today
    • It requires work to fold it into the Pages specification. Is there benefit to do the work? There is work either way since it is still need to be tested with newer versions of pages.
    • If we remove it from the Platform it is a platform work item, but if folded into Pages, it requires the Pages community to agree to do it.
    • I believe there is only 1 repository, mailing list and eclipse project for both of these specifications. Only the specifications are not combined.
    • ACTION: Follow up with pages / debugging community on their thoughts about combining the specifications into one.
  • Milestone 1
    • https://github.com/orgs/jakartaee/projects/20/views/1
    • Arjan expressed that Mojarra was able to stage the old way with nexus and publish to maven with the old way and not have a problem. So either there were things converted there or the old way is somehow working.

Back to the top