Jakarta EE Platform Call

Date: 2025-02-04
Present

• Jared Anderson (IBM)
• Anand NK (IBM)
• Nathan Rauh (IBM)
• Tom Watson (IBM)
• Ed Burns (MSFT)
• Scott Marlow (Red Hat)
• Cesar Hernandez (Tomitribe)
• Jan Westerkamp (iJUG)
• Arjan Tijms (OmniFish)
• Brian Stansberry (Red Hat)
• Bernd Müller (Ostfalia)
• Petr Aubrecht (Payara)
• Dmitry Kornilov (Oracle)

Agenda

Top of mind for Ed, Arjan, Jared

• ACTION: JEA-494-tck-archive-format
  • Related matter that does impact Web Profile certification
    • SHA sum parity, from Ed Bratt
      • If the SHA sum of the bits of the TCK from the normative location (download, or maven central) match the SHA sum of the bits of the TCK used to run the tests and obtain the results, the certification can be valid.
      • In other words, the download location is immaterial as long as the SHA sums match.
• TCK license matters
  • Ed Bratt confirmed: maven central has no prohibition on including EFTL license in binary artifacts included in maven central.
    • Ed Bratt confirmed: as long as the TCK binary includes all the project license(s) and the EFTL license, the license requirements are met. The TCK will implement this requirement by ensuring there is a single LICENSE.md file which includes the union of all the LICENSE* files in https://github.com/jakartaee/platform-tck .
      • Ed Bratt confirmed: This process is acceptable because the ordering of contents in the LICENSE file is irrelevant.
  • Action: https://www.eclipse.org/legal/tck/ can be added to the primary license.md file in https://github.com/jakartaee/platform-tck and remove the https://github.com/jakartaee/platform-tck/blob/main/LICENSE_EFTL.adoc file
• ACTION:
  • Ed Burns to created a tracking https://github.com/jakartaee/platform-tck/issues for this that covers the requirement of producing jars that will be published to Maven Central and have the same sha as is found in the eclipse downloads page zip file. The EFTL license also needs to be in the license.md file contained in the root of that zip. https://github.com/jakartaee/platform-tck/issues/1867
  • Send email to TCK dev list pointing to the issue.
• https://projects.eclipse.org/projects/ee4j.jakartaee-tck/elections/election-edward-burns-jakarta-ee-tck

TCK Refactoring Jakarta EE 11

• TCK call Agenda for tomorrow:
  • https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit?tab=t.0
  • Many jobs breaking. Please be mindful when making changes to look at jobs:
  • ![][image4]

Jakarta EE 12

• Issues labeled for Jakarta EE 12
• Reach out to prospective specifications to gauge interest?
  • Jakarta Config
    • Discuss ideas to allow Jakarta Config to effectively be MicroProfile Config
      • The APIs for Jakarta Config would be the MicroProfile Config APIs, but with jakarta namespace. Yes, a copy/paste.
      • The implementation may delegate to the MicroProfile Config implementation.
      • The Spec document would be one-line: see the corresponding MicroProfile config spec document.
      • The TCK would be a copy/paste of the MicroProfile Config TCK
      • Need to introduce a new line in the ConfigSource (MicroProfile Config API)

        • “Some configuration sources are known as default configuration sources. These configuration sources are normally available in all automatically-created configurations, and can be manually added to manually-created configurations as well. The default configuration sources are:

        • 1. System properties, with an ordinal value of 400
        • 2. Environment properties, with an ordinal value of 300
        • 3. The /META-INF/jakarta-config.properties resource, with an ordinal value of 200
        • 4. The /META-INF/microprofile-config.properties resource, with an ordinal value of 100
      • Can possibly split the API into two. One that CDI can depend on and the other that is CDI based.
      • There is potential that a future version of MicroProfile that supports Jakarta EE 12, that it could drop MP Config from the platform and move to embrace Jakarta Config similar to what was done with Metrics moving to Telemetry
      • RedHat’s concern is that there is a change of governance for Config (and cost) and does not prefer this solution
      • Circular dependency is a concern that leads to this type of solution
      • Future discussions may continue on the platform mailing list and the cn4j mailing list (eclipse archive) (This directive is contested)
  • Jakarta NoSQL
  • Jakarta MVC
  • Jakarta RPC
• APIs with SecurityManager / AccessController / PrivilegedAction references
  • APIs with SecurityManager / AccessController / PrivilegedAction references (Platform issue 1018)
    • Activation (issue and PR)
    • Batch (issue and PR)
    • CDI (issue and PR) PR merged already
    • JSON-P (issue and PR)
    • Mail (issue and PR)
    • Persistence (issue and PR)
    • REST (issue and PR) PR merged already
    • Servlet (issue and PR) (just a javadoc update)
    • Validation (issue and PR) (changes could be done in a service release since 3.1 was new in EE 11)
    • SOAP, XML Binding and XML Web Services also have references to SecurityManager artifacts and could be updated in a minor release independent of EE 12
    • Connector has specification references that need to be cleaned up as well (issue)
      • SecurityPermission annotation that may also need to be deprecated for removal. Needs investigation