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 12th, 2022

Jakarta EE Spec Committee - January 12th, 2022

Attendees (present in bold):


Kenji Kazumura - Fujitsu

Tom Watson - IBM - Emily Jiang

Ed Bratt - Oracle - Dmitry Kornilov

Andrew Pielage - Payara

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

Zhai Luchao -  Shandong Cvicse Middleware Co. - Enterprise Member

 

Eclipse Foundation: Tanja Obradovic, Paul Buck (chair)


Guests: Scott Stark, Scott Marlow


Past business / action items:

  • Approval is requested for the meeting minutes from the December 15th, 2021 meeting as drafted - Approved.


Agenda:

  • Ongoing tracking spreadsheet of individual specs progressing through the JESP

  • Action: Initiate Creation Review ballot for Jakarta RPC

    • Is it appropriate to change the name of the project and initial committers as discussed on the gitlab issue during community review?

      • EMO position is stay with Jakarta RPC

      • The committer list is weighted with reps from one company, however working group member organizations can and are encouraged to assign a committer

    • Ivar to initiate Creation Review ballot

  • EE 10 Release Review pages that have been created so far are short on detail on what has been changed or added in this release. Discuss our review goals so we can leave a consistent record. [Ed]

    • Release text summaries need to be more definitive on what was changed and/or added in a release. It is okay to include links to issues or PMI page summaries. Avoid implementers having to hunt through spec documents (diffs) to figure out what changed.

    • Suggestion: add to mentor checklist.

  • Ivar recommended that the revised ballot template text is used for new ballots being initiated.

  • Call-to-action: Getting Jakarta EE 10 release ballots underway [Mentors]

  • Discussion/action item about explicitly disallowing people from creating or modifying classes under the jakarta.* namespace

    • Java Language spec that explicitly says this is forbidden for java.* and javax.*.  When we migrated to the jakarta.* namespace, we did not explicitly create a similar statement.

    • Do we need to adopt a statement such as:

      • "The packages java, javax, and jakarta are reserved and trademarked.  Applications should not create or modify classes under these packages.  Applications that do so have unspecified behavior and may not deploy, function properly at runtime, or be portable."

        • Or target jakarta.* specifically -- likely legally safer to avoid commenting on java and javax and let that get enforced elsewhere.

      • "The jakarta.* package is reserved and trademarked by the Eclipse Foundation.   It is forbidden to modify, subset, superset or otherwise extend this package without explicit permission from the Eclipse Foundation through the established Jakarta EE Specification Process.  Applications that modify, subset, superset or otherwise extend this package have unspecified behavior and may not deploy, function properly at runtime, or be portable."

    • For namespaces, here’s what is in the EF IP framework today: 

      • See the Eclipse Foundation Trademark Usage Policy which says

        • Proper Usage of Eclipse Foundation Trademarks

          • “4. Only Eclipse Projects are authorized to develop or maintain software packages that use Eclipse Foundation namespaces such as 'org.eclipse' in their namespace. An important use of an Eclipse Trademark is the 'org.eclipse' string used on all namespaces for Eclipse Projects. This naming convention is used to identify code that has been developed as part of an Eclipse Project.”

        • Proper Usage of Eclipse WG Trademarks

          • "Use of any namespaces created by a WG including but not limited to ‘jakarta’, 'org.locationtech' or 'org.polarsys' is not permitted by this Policy unless authorized in advance in writing by Eclipse."

      • Also see the EF TCK License which says 

        • "4.c. comply with any requirements stated in the Specification with regard to subsetting, supersetting, modifying or extending the Specification in any Product claimed to be compatible with the Specification." 

      • Also see the (Jakarta) Compatibility Trademark License Agreement which says

        • “1.11 “Specification-Compatible Implementation” shall mean an implementation that: … (ii) does not modify, subset, superset or otherwise extend the Eclipse Name Space, or include any public or protected packages, classes, interfaces, fields, methods or constructors within the Eclipse Name Space, other than as required or authorized by the Ratified Specification.”

Notes from discussion:

  • Usage of the Jakarta namespace for TCK packages versus application code used by a TCK. It is okay for the TCK, not for application code(?)

  • Are there technical limitations for TCK packages being in the Jakarta namespace?

  • How far do we want to push on allowing TCK to use the Jakarta package namespace? Apparently some products will have issues and will require remediation.

  • Need a clear recommendation, refer to community ballot underway in the Platform Project for consideration (not binding)

  • Proposal: Specification Committee to author the definitive and final position on TCK package naming (binding). Ballot to be initiated on the public Jakarta Spec Discussions mailing list. 

  • Topics for future meetings:

    • “TCK Archive Format”, see [jakarta.ee-spec.committee] [External] : Re: TCK archive format? (Consider allowing JAR or ZIP)

    • The EFSP has been updated to EFSP 1.3, the Specification Committee needs to review and consider future updates to the JESP 1.3 [reference November 3rd minutes]

    • Review the mentor checklist and the Github action for automated review that was proposed in 2021

Back to the top