Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakarta.ee-spec.committee] Review for approval: Jakarta EE Specification Committee Meeting Minutes - February 8th, 2023

The minutes for the February 8th Specification Committee call are below and are also available here. Please review and be ready for approval during our call on February 22nd.

Jakarta EE Spec Committee - February 8th, 2023

Attendees (present in bold):


Kenji Kazumura - Fujitsu

Tom Watson - IBM - Emily Jiang

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, Paul Buck (chair)


Past business / action items:

  • Approval is requested for the minutes from the January 25th, 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


  • Draft resolution for optional features in the Platform specification (also see issue #54), to be put forward for ballot in the 02/08 call:

    • "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.”


The resolution was put forward by Scott Stark and seconded by Tom Watson


Kenji Kazumura - Fujitsu [+1]

Tom Watson - IBM - Emily Jiang [+1]

Ed Bratt - Oracle - Dmitry Kornilov [+1]

Andrew Pielage - Payara - Petr Aubrecht [+1]

David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez  [absent]

Ivar Grimstad - PMC Representative [+1]

Marcelo Ancelmo - Participant Member -  Abraham Marin-Perez [0]

Werner Keil - Committer Member [absent]

Scott Stark - Red Hat - Scott Marlow  Enterprise Member [+1]

Zhai Luchao -  Shandong Cvicse Middleware Co. - Enterprise Member [+1]


7 +1 /  1 0 / 0 -1 / 2 absent 

This resolution passes


Action: Drop a note to communicate this outcome on the jakartaee-spec-project-leads, jakarta.ee-spec and jakartaee-platform-dev mailing lists [Scott Stark]


  • Formalizing the compatibility requirements for specifications in the JESP [1.] and then updating the Compatibility Requirements page [2.] of the Jakarta EE Platform project to provide clarifying info and context in the form of the Q/A section:

  1. https://github.com/jakartaee/specification-committee/issues/72

  2. https://github.com/eclipse-ee4j/jakartaee-platform/issues/605

-First step is to document the compatibility requirements that properly reflects the current practice of Jakarta EE and in particular what the semantic version model is that has been adopted including requirements for major, minor & service releases [start here]

-Need to also document the necessary guidance for TCKs, proposed updates to the TCK guide 

-Cover the deprecation protocol for existing interfaces, deprecated before removal. Requirement for deprecation notice to be at least one major release before removal

-Breaking changes can be introduced by changing default behavior, updating interfaces

-For any breaking change including deprecation, how to notify of this pending change?

-Document deprecation and breaking changes in the project’s release plan (if known at that time)? Could be done in a milestone release of the spec document to help communicate earlier

-For APIs could there be a warning message emitted before removal?

-Suggestion: Update the JESP to require a spec project to create a Milestone and engage in a Progress Review if a breaking change is introduced that was not documented in their Plan Review

-Provide tooling support for application of the semantic versioning model 

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

-References:  

https://docs.osgi.org/whitepaper/semantic-versioning/

https://bnd.bndtools.org/chapters/170-versioning.html

https://semver.org/


  • Looking for a  volunteer from the Spec Committee for the Jakarta EE Community call scheduled for Tuesday Feb 28, 2023 12:30pm – 1:30pm (EST)

    • Jakarta EE 11 Narrative and Direction [10 minutes]

      • Presented by the Platform Project and Specification Committee participants

Proposal the content from Steve Millidge’s Jakarta EE 11 deck

Other resources for the presentation could be: Steering Cmte Resolution for Jakarta EE 11 and Jakarta EE 11 Discussion document

To be revisited in our next meeting on February 22nd

Back to the top