Skip to main content

Jakarta EE Platform Call

Date: 2023-09-26


  • Jan Westerkamp (iJUG)
  • Ed Burns (MSFT)
  • Arjan Tijms (OmniFish)
  • Ivar Grimstad (Eclipse Foundation)
  • Jared Anderson (IBM)
  • Emily Jiang (IBM)
  • Jim Krueger (IBM)
  • Nathan Rauh (IBM)
  • Tom Watson (IBM)
  • John Clingan (Red Hat)
  • Petr Aubrecht (Payara)
  • Dmitry Kornilov (Oracle)
  • David Matějček (OmniFish)
  • Ed Bratt (Oracle)
  • Scott Stark (Red Hat)
  • Cesar Hernandez (Tomitribe)
  • Kenji Kazumura (Fujitsu)

Agenda and Minutes

EE < 11 meeting:

Milestone releases

  • Communicate M1 date. December 5 proposed
    • How to communicate:
      • Platform project dev list
      • Individual emails to component spec leads
      • Spec leads mailing list
      • Spec project list for each component spec
    • What to communicate:
      • Requirements from below
      • You must (component spec) do a milestone M1 release by pre-2023-11-28.
        • You should be able to put at least one of the new features in your release plan into this M1.
        • If you can’t do that, release the previous version as M1.
      • By the way, on M2 you will need to have
        • TCK
        • Implementation
  • What is the audience of M1?
    • An end user artifact?
    • The vendors.
  • What are the requirements of M1
    • API jar
    • Spec document
    • Javadocs
    • XML schemas (if the spec has XML schemas)
  • Optional for M1
    • TCK
    • Implementation
  • Which repository to stage the artifacts for M1?
    • Maven central

Start with a SNAPSHOT release before M1

Discussion about the meaning of maven central vis a vis Cyber Resilience Act.

  • Eclipse open letter [Open Letter to the European Commission on the Cyber Resilience Act Eclipse News, Eclipse in the News, Eclipse Announcement](
  • Jan and Arjan dissent that Maven central should be used for M1.
  • Vendors want Maven central used for M1.
  • Ed would like to make sure that our community has at least made a request of the vendors to expand their view of what is an acceptable repo to pull from for a non-final release.
    • Vendors: because we have a requirement for reproducible builds, for all builds, even things the vendors do not ship, we must only use an immutable repository. Therefore, we cannot depend on a mutable repo.

Jea-102 Edit spec document to apply the ruling of the spec committee regarding optional specifications. Seeking assignee for subtasks.

Jea-201 Schemas

Follow up from last week regarding exception sought by Faces regarding backward compatibility requirements

  • Emily did bring this up at the previous spec committee meeting. It was approved. \

Back to the top