[jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - A

[Andrew Pielage <andrew.pielage@xxxxxxxxxxx>]

Jakarta EE Spec Committee - August 20th, 2025

Attendees (present in bold):

Kenji Kazumura - Fujitsu

Emily Jiang - IBM - Tom Watson

Ed Bratt - Oracle - Dmitry Kornilov

Andrew Pielage (chair)  - Payara - Petr Aubrecht

David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez

Ivar Grimstad - PMC Representative

Marcelo Ancelmo - Participant Member -  Abraham Marin-Perez

Werner Keil - Committer Member

Jun Qian - Primeton Information Technologies - Enterprise Member

Zhai Luchao -  Shandong Cvicse Middleware Co. - Enterprise Member

Guest - Jakarta EE 12 co-release coordinators: Jared Anderson, James Perkins

 

Eclipse Foundation: Tanja Obradovic

Past business / action items:

• Approval is requested for the minutes from the August 6th, 2025 meeting as drafted - Quorum not reached

Agenda:

• EE 11 Update [Ed Burns]
• Retrospective update
• [Carry over from July 9th]: 
• Retrospective was done on the platform call (issue link, document link)
• Need to review retro link to figure out what may need action by spec committee vs others
• Any remaining business on EE11
• Jakarta EE 12 Update [Jared Anderson]
• Platform calls on break until the 26th August
• Jakarta EE Namespace
• [Carry over from July 23rd, August 6th]:
• Discuss straw poll results/voting and actions
• Do we run the straw poll again with only options 1 and 4?
• Do we want to simply accept MicroProfile retaining its namespace for now, and finish defining the rules later?
• What would be the impact if we accepted MicroProfile now, but then made a rule stating all specifications must use jakarta.*?
• There are existing process controls to prevent them doing further releases until they comply
• The Platform team can rule that all specifications contained in the specification itself must use the jakarta.* namespace, and “kick out” or freeze any specifications which don’t comply. These specifications would then just exist as “standalone” Jakarta specifications
• This would be balloted by the Platform committers, not us.
• With only this rule in place, this would not prevent the component specification from continuing to do releases - the new versions would just not be included in the Platform specification.
• If we make a general JESP (or similar) change to the overall Jakarta working group, this would apply to all Jakarta component specifications and we could then vote -1 (against) any new versions of the specifications as not meeting the requirements for a release.
• Should we just have “guidance” of expectations rather than a strict ruling?
• Does there need to be a straw poll in the Platform?
• The JESP currently mandates javax to jakarta, anything else is up to the component/umbrella specifications
• What actually are the expectations?
• If we left the rule as is, then the individual specifications (Config, Fault Tolerance, etc.) could come across with their existing namespace, and continue to do releases as any other Jakarta specification.
• Jakarta Platform currently consumes Web Profile, which in turn consumes Core Profile
• Currently there cannot be something in one of the consumed specifications that is not a part of the consuming specification e.g. there can’t be a specification in Core Profile which isn’t a part of Web Profile or Platform
• To be pulled into one of these umbrella specifications, the individual component specification will need to comply with any rules those specifications define (namespace or otherwise).
• If Web Profile doesn’t want to include all of the MicroProfile component specifications, a new Jakarta Micro Profile umbrella specification could potentially be created to exist as a separate umbrella which would not need to be consumed by the Web Profile or Platform.
• To decide when we have quorum: 
• Do we want to assign an investigative writeup of pros vs cons of defining it as a Jakarta working group wide rule (e.g. JESP rule) vs. delegating any namespace decision to the Platform team?
• Continue discussion next call
• Ongoing tracking spreadsheet of specifications progressing through the JESP specification version lifecycle
• Not discussed
• Issue #55 - TCK Archive Format [Ed Bratt]
• Not discussed
• Check in on Ed Bratt’s PR: pending
• Issue #83 - Clean up and clarify how to list TCK service releases on spec pages [Andrew Pielage]
• Not discussed
• Check on progress of pull requests
• Issue #74 - TCK challenge automatic acceptance - [Ed Bratt]
• Not discussed
• Check on progress of specifications
• Issue #58 - TCK challenge templates [Andrew Pielage]
• Not discussed
• Check on progress of pull requests
• Issue #82 - Consistent approach for TCK challenge exclusions [Ed Bratt]
• Not discussed
• Carry over from February 19th: TCK Process should be updated with something akin to Scott Starks suggestion.
• Review other open issues:
• Not discussed
• Determine which issues to label as “enhancement” and add to our board
• Close issues which are no longer relevant or have been dealt with

--

Andrew Pielage
Senior Software Engineer

		payara.fish
		+448005385490

Try our fully managed cloud native application runtime. 15 day trial available. Payara.cloud

Payara Services Ltd, Registered office: Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ, United Kingdom
Registered in England and Wales: 09998946 | VAT: GB 193854467

Payara is a proud recipient of the prestigious Queen's Award for Enterprise: International Trade 2021