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 - January 25th, 2023
Jakarta EE Spec Committee - January 25th, 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, Wayne Beaton (chair)


Past business / action items:

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

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

01/25/23 Wayne joined the Specification Committee meeting to follow-up on this topic

  • EF position is that provided this source is pulled from an EF where the committers have signed the ECA this situation is covered, having an overlap in the committers strengthens this position

  • Tom observed that there was a non-legal problem that had to do with project API being out of sync w/ the specification, the situation with Faces and “Mojarra” is not desirable

    • Should the JavaDoc and signature tests be generated from artifacts that are part of the spec project? This would apply to all elements that are normative to the spec

    • Topic to be added to the agenda of a future call, and consider specific guidance for Faces and Mojarra.


  • 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

01/25/23 Tanja to report back on further input on the request from the Chinese members

  • Initiatives underway to provide overview docs for the specs and a Jakarta EE tutorial - proposal is to translate these documents first, and then over time translate the spec documents too - target audience are application writers and implementers of the specifications, the English documents are normative

    • For the spec documents this would be done outside of the project, to be considered externally provided documentation  

      • Question was raised on where to host the translated documents? Proposal - Make them available on the Chinese translated website on the spec project’s page.

    • Input from Ed Bratt and Kenji Kazumura provided on the mailing list after the call 

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



Back to the top