Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2024-12-17
Present:

  • Jan Westerkamp (iJUG)
  • James Perkins (Red Hat)
  • John Clingan (Red Hat)
  • Ed Burns (MSFT)
  • Jared Anderson (IBM)
  • Anand NK (IBM)
  • Nathan Rauh (IBM)
  • Tom Watson (IBM)
  • Ivar Grimstad (Eclipse Foundation)
  • Arjan Tijms (OmniFish)
  • Petr Aubrecht (Payara)
  • Ed Bratt (Oracle)
  • Gurunandan Rao (Oracle)
  • Dmitry Kornilov (Oracle)
  • Emily Jiang (IBM)
  • Bernd Müller (Ostfalia)

Top of mind for Ed, Arjan, Jared

  • Next call: January 7, 2025
  • Modify CI jobs for all EE 11 to comply with Spec Committee’s process for TCK jars pushed to Maven Central.
    • Do this before releasing the Core Profile jars to maven central.
    • See official document from spec committe.
      • ACTION: Ed to take this action: push the executables to Maven Central
        • Currently, the zip file has these jar(s) embedded within the published ZIP. Instead, the above process requires these jar(s) to be explicitly published along side the zip.
        • This request originated from Roberto Cortez from MicroProfile: https://www.eclipse.org/lists/jakartaee-tck-dev/msg02076.html
        • This enables the:
          • The SHAS to stay the same
          • Preserves the license files
    • Also need to do this for EE 10 (need to understand how we can do such a thing retroactively).
  • Example of the type of failures that we keep running into with the TCK refactoring:
    • https://github.com/jakartaee/platform-tck/issues/1699
    • Totally unique problem (we haven’t encountered this specific one before after ~6 months)
    • The point of bringing this up:
      • Only related to the tests itself
      • Completely unrelated to GlassFish or any other server being tested
      • Illustrate the continued existence of the emergence of unknown unknowns. Each such emergence can introduce a very wide range of delay.
  • Guru suggested an idea for satisfying the Persistence test requirement:
    • We have the component spec TCK for persistence 3.2 that has been running and passing for six months.
      • Could we combine this with the existing, passing, platform persistence tests, and call that good enough?
    • Ed asked for discussion from the spec committee members who are also in the Platform project call if this idea would still pass the ballot process for the specification committee.
      • Emily asked, but what about the use of Eclipselink, instead of GlassFish? I think you need to run in the container, not standalone.
      • The discussion proceeded to the topic of what is the current state of affairs for the TCK tests “in container” or “Java SE” mode.
    • Tom elicited that this proposal includes the assumption that if you run the tests outside the container, they will also run inside the container which is not a valid assumption.
  • Platform TCK did agree to focus on Web Profile TCK
    • Continue to work on persistence, EJB lite, assembly, signaturetest
    • Separating out the persistence tests that are only in the Platform.
      • This is implemented using JUnit tags.
    • Guru asked for us to define a plan of record for the case when challenges are raised to tests that are both in the Web Profile and Platform.
      • Consider this scenario:
        • Complete the Web Profile
        • During the Platform process, one of these common tests is challenged.
        • What happens to the instance of this test in the Web Profile? This may happen in connection with a technology that is only present in the Platform profile?
      • Proposals
        • make a copy of the test in question
        • Complete the Web Profile TCK first, but do not go to ballot with the Web Profile.
  • TCK refactoring project understaffed.
    • Currently
      • Oracle: 2 staff members full time
        • Red Hat: 1 staff member full time, often 2
        • IBM: 1 staff member part-time
        • Microsoft: 1 staff member part-time (coordinating)
        • OmniFish: 1 staff member part-time
        • Payara: 0
        • Tomitribe: 0
        • Fujitsu: 0
    • Do any of the members not contributing yet have engineering resources to donate to the effort?
  • Source of truth of what tests are actually running and passing

![][image1]

Jakarta EE 11

Back to the top