Skip to main content

Jakarta EE Platform Call

Date: 2021-02-23


  • Scott Marlow (Red Hat)
  • Kevin Sutter (IBM)
  • Ivar Grimstad (Eclipse Foundation)
  • Ed Bratt (Oracle)
  • Dmitry Kornilov (Oracle)
  • Thomas Watson (IBM)
  • Tanja Obradovic (Eclipse Foundation)
  • BJ Hargrave (IBM)
  • Brian Stansberry (Red Hat)
  • Paul Nicolucci (IBM)
  • Ryan Cuprak (Jakarta EE Ambassadors)
  • Emily Jiang (IBM)
  • Lukas Jungmann (Oracle)
  • Steve Millidge (Payara)
  • Cesar Hernandez (Tomitribe) Jean-Louis Monteiro (Tomitribe)
  • Kenji Kazumura (Fujitsu) Werner Keil (Jakarta EE Ambassadors)

”” Agenda and Minutes

[KWS] Jakarta EE 9.1

  • EE4J Parent POM 1.0.7 will be released as soon as Jenkins issues have been sorted out
  • GlassFish 6.1 update
    • JDK 11 version merged to master
    • Quick tests does not currently pass
      • Fujitsu and Arjan working to fix the quick tests
  • TCK
    • GlassFish running on JDK 11, TCK running on JDK 11. With failures
    • Changes being made to make CORBA tests optional for EJB (pr + issue)
    • The PortableRemoteObject#narrow changes affects ~800 tests
    • jakartaee-tck/issues/621 is the tracking issue.
    • CDI TCK uses but not the TestHarness project that is used by Platform TCK.
    • Aside… Open Liberty is having good luck with running the nightly TCK with JDK 11. Success rate is around 99.9x%. (Open Liberty does not implement all optional pieces of the Platform, so the current process does not allow it to be the CI for the Spec version.)

[KWS] Service Release update

  • This modified process should be finalized at tomorrow’s Spec Committee call and then this clarified Service Release process can be more widely communicated.

[EB] Discussion about TCK changes

  • Refactoring vs. Separating
    • DI, CDI, BV are separate. All others are included in Platform and WebProfile and qualify product compatibility.
  • Possible proliferation of test frameworks – JavaTest, Arquillian, Test NG, JUnit, Others?
  • Vendor input?
  • Discussion:
    • [KWS] Wide open test harness selection could be problematic for vendors.
    • [SM] Configuration changes already have impact. Additional TCK runners would complicate things
    • In general – consistency in configuration and common tools
    • [DK] – Would recommend some set of tool standards. Citing expansive tooling in other frameworks
    • [Werner] – Could the TCK check Module definitions as the JDK now provides an extensive Module API?
    • [EJ] – Popular frameworks wherever possible.
    • Guidelines are needed! We (the platform team) must start the work with defining these guidelines to allow for component specifications to start extracting and refactoring their TCK. JSON Binding and Processing could be looked at for examples. No-one objected to the idea of defining guidelines.
    • [EB] – Vendor inclusion in this effort is important

Back to the top