Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - March 22nd, 2023
Jakarta EE Spec Committee - March 22nd, 2023

Attendees (present in bold):


Kenji Kazumura - Fujitsu

Emily Jiang - IBM - Tom Watson

Ed Bratt - Oracle - Dmitry Kornilov

Andrew Pielage - 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

Scott Stark - Red Hat - Scott Marlow  Enterprise Member

Zhai Luchao -  Shandong Cvicse Middleware Co. - Enterprise Member

 

Eclipse Foundation: Tanja Obradovic, Wayne Beaton, Paul Buck (chair)


Past business / action items:

  • Approval is requested for the minutes from the March 8th, 2023 meeting as drafted - Approved.


Agenda:

  • Ongoing tracking spreadsheet of specifications progressing through the JESP version lifecycle

  • Ongoing work on and resolve Specification Committee’s process enhancements items including those identified in the Jakarta EE 10 retrospective:

    • Issues with the “enhancement” label are here 

    • Enhancement labeled issues in a project board is here 

See the issues in the board for updates

  • Follow-up on two topics from previous meetings:

    • Optional features approved resolution: "An individual specification can have optional features, however when a component specification is included in the Platform and Web Profile, and Core Profile an optional feature must be explicitly declared as required, otherwise it is not required. This requirement is noted in the Platform specification.”

Action: Create the issues of what needs to be done including a draft of the Jakarta EE semantic versioning model [Scott Stark]

https://www.eclipse.org/lists/jakarta.ee-spec/msg02845.html

Discussion continues on the mailing list, input to be considered prior to inclusion in the EE 11 Platform spec.

https://www.eclipse.org/lists/jakarta.ee-spec/msg02853.html

“Platform specifications don’t define optional features. An individual specification can have optional features, however when a component specification is included in the Platform and Web Profile, and Core Profile, an included optional feature must be explicitly declared as required, otherwise it is ignored. This requirement is noted in the Platform specification.”

General agreement that the above text is acceptable to the specification committee.

Discussion: 

  • Regarding whether guidance should be provided to component specifications that optional features are discouraged?

  • Should guidance also be provided to component specification TCK’s need to be configurable to not require the tests for optional features - likely not needed as a TCK challenge could be issued if it was working that way.

  • Suggestion: Platform project to discuss best practices for component specifications handling optional features

Regarding component specifications:

Note for reference - From August 25th, 2021  - See ballot results for the “RESOLUTION: The Jakarta EE Specification Committee resolves that no new optional features may be added in Jakarta EE 10 and beyond in component, Platform, or Profile specifications.”

  • This resolution remains in effect and applies adding “new optional features”

  • Do we want this resolution to stand as written regarding component specifications?

Next steps are with the Platform project to discuss and consider appending the August 25th resolution to the discussion thread.

Issue created by Scott Stark of what needs to be done, see

https://github.com/jakartaee/specification-committee/issues/73

Proposal - shift this topic to the Platform Project, focus is on automation of testing of compliance with the semantic versioning model to flag problems w/ backward compatibility. There are discussions regarding using the OSGi BND tool and the namespace the tool uses. 

Note CDI 4.0 did introduce a backward in-compatible change which was inconsistent with the guidance in the Compatibility Requirements page.

Given that situation, we do need to:

Clarify the Jakarta EE semantic versioning model and then

  • Update the JESP if needed

  • Update the Compatibility Requirements page

Or we can start with a discussion regarding should Jakarta EE allow backward compatibility changes? Yes

Homework - carefully review the Compatibility Requirements page

Adopt a tool to detect any backward compatibility problems to assure consistency w/ the agreed to semantic versioning model



Back to the top