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 - January 11th, 2023

The minutes for the January 11th Specification Committee call are below and are also available here. Please review and be ready for approval during our call on January 25th.

Jakarta EE Spec Committee - January 11th, 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 November 30th, 2022 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

  • Request from Eric of Primeton (mengqy@xxxxxxxxxxxx) to the Marketing Committee:

    • Do we have the authority to translate specs of Jakarta EE (Jakarta EE Platform, etc.) and publish that on the website in China?

    • Discuss formulate the Specification Committee’s questions and/or position, notes from the discussion:

      • Tanja plans to reach out to the Chinese community members on what information they are looking for and are the translated specs going to fulfill that need?

      • The English documents are normative.

      • The EF is currently assessing this from a licensing perspective including copyright.

      • Other bodies provide translated versions for ease-of-use. 

        • For example the JCP provides Japanese translations for the spec docs, JavaDoc and APIs, lag by 2 to 3 months.

      • Any implementor must have English skills, Java and the spec JavaDoc pages are in English

      • The specs do provide helpful information to the community

      • We are not going to add spec doc translations to the release, we cannot add burden to the projects or lengthen the release cycle

      • What about focusing on other materials such as the tutorial (out of date) as an alternative or in addition to?

      • Critical - whenever there is doubt, the English documents are normative

      • Any commitment to do this must be on going for subsequent releases

    • Tanja to report back on further input on the request from the Chinese members

  • Steering Committee’s 01/09/23 Jakarta EE 11 guidance, for reference see: 

    • Jakarta EE 11 (10.x) - Narrative

    • Adopted Resolution: “Resolved, the Steering Committee recommends that the Jakarta EE Working Group begin planning for the next Jakarta EE 11 release as proposed in the Jakarta EE 11 Narrative Presentation, with the following high level guidelines: 

      • Target Java version 21 

      • Target GA date Q1 2024

      • Priorities 

        • Unified APIs improving Developer Experience

        • New Specifications

        • Build on the Latest Java

        • Enable Community Contribution

These guidelines are provided to encourage a common community direction for Jakarta EE 11.“ 

  • 11/15/22 Does the EFSP mandate that authoritative sources live within a specification project?  That is source input that ends up producing the final specification content [Tom]

    • API JAR’s are provided as a convenience, they are not normative. The JavaDoc and signature tests are part of the spec and therefore normative.

    • Is it a requirement that the sources used to create normative artifacts required to be managed as part of the specification project’s sources?

    • Is there a situation where a committer may have merged an artifact from sources outside of the project that has provenance elsewhere?

    • Is there a situation where there is a committer on an open source project that is not a committer on the specification project, where that committer has contributed to an artifact that is normative?

      • Scott Stark commented: This is the fundamental question given that implementation projects don't have a requirement that committers sign the specification working group agreement. If you think about this in terms of provenance as discussed in the current push for SBOMs, I don't think we want a situation where any source feeding into a specification project artifact is from a repo outside of the specification project.

    • Need to establish policy (if required) that apply to all specs

    • 11/30/22 Wayne Beaton joined the meeting on November 30th to explore this topic further with the Specification Committee.

A discussion took place to help Wayne understand the situation, he will now consider it and consult with others in the Eclipse Foundation and update the committee at a later date.

FOLLOW-UP w/ Wayne scheduled for 01/25/23 Specification Committee meeting


Back to the top