| [jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - November 3rd, 2021 |
Attendees (present in bold):
Kenji Kazumura - Fujitsu
Kevin Sutter - IBM - Tom Watson, Emily Jiang
Ed Bratt - Oracle - Dmitry Kornilov
Andrew Pielage - Payara
Scott Stark - Red Hat - Mark Little, Scott Marlow
David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez
Ivar Grimstad - PMC Representative
Marcelo Ancelmo - Participant Member - Martijn Verburg
Werner Keil - Committer Member
Jun Qian - Primeton - Enterprise Member
Zhai Luchao - Shandong Cvicse Middleware Co. - Enterprise Member
Eclipse Foundation: Tanja Obradovic, Paul Buck (chair)
Past business / action items:
Approval is requested for the meeting minutes from the October 20th meeting as drafted - Approved.
Agenda:
Ongoing tracking spreadsheet of individual specs progressing through the JESP
Jakarta EE 10 Plan Review - Candidate specifications
Spec process discussion [All]
The EFSP has been updated to EFSP 1.3, the Specification Committee needs to review and consider future updates to the JESP 1.3, decide on next steps including timing. The JESP repo is here. Redline is here.
JESP has issues pending
EE10 we will remain on JESP 1.3 (based on EFST 1.2)
There is careful assessment and discussion required to reconcile EFSP and JESP and also deal with the backlog of issues
Proposed next step: review the differences, summarize the outstanding issues, on or before the conclusion of EE 10
Where do record the version of the JESP (EFSP)
Action: Revist in first call in 2022
Output format for TCKs [Ed]
Implementers are having challenges when it comes to parsing and collecting up the output of TCKs for presenting as evidence that the product iscompatible. Do we think there is consensus around regularizing this output? Is this something the Specification Team should take up and try to develop a guide, or possibly a requirement about?
Issue raised for the Platform Project to explore the topic and overtime make recommendations to the Specification Committee to be ratified and adopted. Not in scope for Jakarta EE 10.
JPMS module name [Scott Stark]
The Jakarta EE10 release plan defines JPMS module names in terms of this spec committee doc https://github.com/jakartaee/specification-committee/blob/master/names.adoc
This spreadsheet contains the then current module name and the proposed module name for 9.x
Proposal: add an explicit JPMS module name column to this document to capture the module-info naming conventions for EE10
Existing usage if it is consistent with the following
API_PACKAGE non-jarkata package root if it makes sense (for CDI it does not)
Some variation of the existing project Code column
Scott to apply the proposed naming convention to all projects, and open a PR to update the naming doc accordingly. Will not affect specs that already have a JPMS module name.
The proposed (and now adopted) naming convention as best practice will be documented after the table in the names.adoc page.