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 - April 19th, 2023

Jakarta EE Spec Committee - April 19th, 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 (not available)

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 April 5th, 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.

04/05 - Topic was not discussed by the Platform Project in their most recent call, a reminder will be sent to the chair to include in the next call (04/11?).

04/19 - Proposal: Specification Committee to rescind its 08/25/21 resolution 

“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.”

and consider it superseded by subsequently approved 02/08/23 resolution above.

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

Committee’s position the proposal documented above: 

  • No objections were noted regarding the above updates/edits to the 02/08/23 resolution

  • No objections were noted regarding the 02/08/23 resolution as updated 04/19/23, superseding the 08/25/21 resolution

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

04/05 A copy of the Backwards Compatibility page was made in a google doc where suggested edits were made and discussed on the call. Further refinements can be made in the document and reviewed in the Committee call on 04/19.

04/19 Continue review and refine the proposed updates to the Backward Compatibility page in the google doc

  • Discussion was had based on the comments from Scott Stark in the google doc regarding not starting w/ the Backward Compatibility page and evolving that doc, rather start with how semantic version applies 

  • Key question is are we going to allow incompatible changes? If yes, then semantic versioning is an option

  • In Jakarta EE 10 a number of specs including CDI behavior change made backward incompatible changes

  • Should Jakarta EE adopt a hybrid versioning model? Not a pure implementation of Semantic Versioning.

  • Idea: Apply semantic versioning to the component specifications, they are then responsible for how backward compatibility is retained?

  • Consider adopting a model similar to Java SE?

  • Straw poll - anyone object to backwards incompatible changes being permitted? 

    • Consensus: no objections

    • Next step: Work is required to clarify when and how it is done in managed way 

  • Are there any objections to the current non-voting Specification Committee chair, Paul Buck, continuing to serve for another 12 months?

    • No objections, the current non-voting chair will serve for another 12 months


Back to the top