| [jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - July 14th, 2021 |
Attendees (present in bold):
Kenji Kazumura - Fujitsu
Dan Bandera - IBM - Kevin Sutter, Tom Watson
Ed Bratt - Oracle - Dmitry Kornilov
Andrew Pielage - Payara - Matt Gill
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
Eclipse Foundation: Tanja Obradovic, Paul Buck (chair)
Past business / action items:
Approval is requested for the meeting minutes from the June 30th meeting as drafted - Approved.
Agenda:
Ongoing tracking spreadsheet of individual specs progress through the JESP
Jakarta EE 10 Plan Review - Candidate specifications
Proposal from Dan, Kevin and Scott S. for how to handle optional features in Jakarta EE specifications including Platform and Web Profile. The proposal is here (see June 2nd minutes for additional background)
[06/16]Dan and Paul authored a resolution:
DRAFT RESOLUTION (added during the call): Is to eliminate marking any Jakarta EE Specification feature as optional in some future release of each Jakarta EE Working Group Specification, including and possibly starting with the Jakarta EE Platform Specification Release 10. All remaining features would be required.
Clarifying text to the proceeding resolution: The process would be to mark all optional features in the current release as “Deprecated” in a new Minor release (Release 9.2), and in a subsequent Major release (not necessarily the very next Major release) eliminate the Deprecated feature completely from the Jakarta EE Platform Specification. Eliminating these Deprecated features is not retroactive to earlier released specifications, which will continue to exist. As implied, “Deprecated” will be defined as a way of marking a feature as on the path to complete elimination from some future release, and it indicates to the public “this feature is going away”. This two-step process provides a formal communication mechanism within the specification itself for the Working Group to signal to the community that a feature will definitely be removed from a future release. The intent is to mark current features marked as “Optional” as “Deprecated”, but in the future even “Required” features could be marked as “Deprecated” should the Working Group decide to prune little used features from the platform. This two-step process will take longer but will also give consumers of the platform a longer runway to plan for and deal with the elimination of the feature should they wish to consume that future platform release.
[06/16] Agreed to next steps:
1. Specification Committee members have requested time to review the resolution, and provide input on the Spec Committee mailing list over the next 7 days. [Done - Kevin posted to jakarta.ee-spec.committee at Wed, Jun 16, 2:59 PM]
2. Following 1., send the proposal on optional features: draft resolution, clarifying text & the final version from the original document to Spec Project Leads mailing list to explain dissenting views or counter proposals over 7 days.
3. Target to ballot on the resolution in the Spec Committee call on June 30th.
Review the discussion that occurred on the list (see 1. above) and assess next steps required to get to 2. and 3.
[06/30] Dan has reviewed the discussion thread on the mailing list and proposed that the resolution be redrafted to reflect the input. Key objective is to allow for other (besides Glassfish) CI to fully implement the Platform Specification and over time eliminate optional features.
Scott mentioned that being dependent on one and only one CI creates potentially undue exposure to the releases of Jakarta EE. Objective is to increase the pool of CIs that could be a ratified final CIs.
Dan asked that an investigation be done to determine which optional features if dropped, would make it possible for other CIs (besides Glassfish) to be a ratified final CIs.
Question: Does the Web Profile have any optional features? On the call the assessment was No.
[06/30] Request to non-Glassfish open source Jakarta EE Platform implementations (ie. WildFly & OpenLiberty) - what is the set of features that are optional and are not implemented in the platform?
[07/11] Also see email thread initiated by Ed Bratt [jakarta.ee-spec.committee] [External] : Re: Discuss proposed Resolution for eliminating Optional aspects of Specifications Mon, Jun 28, 8:03 PM
Discuss next steps to get to a proposal and voting resolution
[07/14] Dan in his email to the Spec Committee proposed: I proposed we define "Deprecated" formally and its meaning in a revised Jakarta EE Specification Process (JESP), mark Entity Beans and the Embeddable EJB Container, as Deprecated immediately, and mandate that Compatible Implementations need not implement Deprecated features to qualify for finalizing Jakarta EE Specifications.
Discussion:
Note: With the next rev of the EFSP potentially removing the requirement for ratified CIs to implement all “optional” features, the definition of a “ratified CI” falls on each Project’s shoulders. So, eventually (when we adopt the updated EFSP 3.2), we will have to define the parameters for a ratified CI as they relate to optional/deprecated features and consider updates to JESP if required. TODO item for the (near?) future, regardless of the outcome of this specific discussion.
Why not mark all optional features as deprecated (and ultimately removed, that said, if shipped, the tests must be passed) This would be a major effort and each of the situation of affected items needs to be understood/impact analysis
Is (Ed’s) the hierarchical approach an option?
Is Dan’s proposal a pragmatic approach that is an acceptable incremental step forward for Jakarta EE 10 - And get 2 additional possible implementations that are CI candidates. Question: are there other implications to the deprecation of Entity Beans and Embeddable EJB Container?
Can we remove features or specifications and have them re-added by vendors and included in their implementations? And pass the applicable TCK and make statements of compatibility, these TCKs need to exist. Note: such specifications are not “optional”, they are simply standalone Jakarta EE specifications.
Assertion: platforms (profiles) should not have “optional” features, what’s in a profile is mandatory
Complicating factor: What is optional today is not well defined or understood. Going forward should spec projects be clearer on what features are optional and implementers clear on which optional features they implement?
Candidate consensus on a first step:
No new optional features in the Platform or Web Profile in Jakarta EE 10
Remove these 2 optional features: Entity Beans and Embeddable EJB Container
Spec projects be clearer on what features are optional and implementers clear on which optional features they implement
Guidance on how to document to be provided to projects from the Specification Committee
Paul documented the candidate consensus in an email posted to the Specification Committee mailing list for further discussion.
Plan Review ballot results are missing from these specification web pages:
Mail 2.1 - Andrew Pielage
XML Binding 4.0 - Marcelo/Martijn
XML Web Services 4.0 - Jun Qian
Activation 2.1 - David/Jean-Louis
Security 3.0 (Page is missing for 3.0) - David/Jean-Louis
Follow-up in the call on 07/28 to see that pages have been updated