Skip to main content

Jakarta EE Platform Call

Date: 2023-06-13

Present:

  • Ed Burns (MSFT)
  • Lenny Primak (Individual)
  • Scott Marlow (Red Hat)
  • Jan Westerkamp (iJUG)
  • Ivar Grimstad (Eclipse Foundation)
  • Jesse McConnell (Webtide)
  • Ed Bratt (Oracle)
  • Jared Anderson (IBM)
  • Emily Jiang (IBM)
  • Jim Krueger (IBM)
  • Nathan Rauh (IBM)
  • Dmitry Kornilov (Oracle)
  • Cesar Hernández (Tomitribe)
  • Jen-Louis Monteiro (Tomitribe)
  • David Matejcek (OmniFish)
  • Tanja Obradovic (Eclipse Foundation)

Agenda and Minutes

Resolved: Ed and Arjan to alternate weeks running this meeting, starting next week.

ACTION: Getting all specs through Plan Review

  • EE11 labeled issues
  • Wave discussion: see https://github.com/jakartaee/jakartaee-platform/issues/685
  • Discussion about non-binary dependencies
    • Jakarta REST does have a non-binary (behavioral, or integration) dependency on Servlet. For example, impact of ServletContainerInitializer.
    • JSF ExternalContext has dependencies on Servlet and Portlet.
    • Agreement that the wave discussion does need to take those into account.
      • Jan suggested we explore some ways to quantify these non-binary (behavioral or integration) dependencies.
      • This relates to the extent to which the api jar is a part of the specification or not.
      • Another dimension of complexity is the TCK interdependencies.
    • Agreement that we take the current state of the Wave discussion and move it on.
      • Ed asked how did we address this in < EE11?
      • Scott mentioned there was some level of hand-waving. But in 11, actually making solid progress on this interdependencies is a goal of 11.
      • Emily and Lenny asked how much effort are we willing to put on this particular effort in 11?
      • Jan brought up again the goal of compliance with JPMS. At least in the core profile first. We need to be sure about Wave 0, 1, 2. The others we can solve later.
  • Nathan brought up the question of what about the proposed new specs?
    • ACTION: Ed to kick off discussion on new-to-EE11 specs on platform-dev. These notes are meant to capture the dimensions of discussion.
      • See “monthly” from 2023-06-06.
      • Jakarta NoSQL
        • Marlow: Last week, we asked some Jakarta NoSQL questions, https://www.eclipse.org/lists/nosql-dev/msg00232.html has answers to these and related questions.
        • The absence of a clean JDBC style driver concept and platform spec integration is a problem. This would argue for keeping it standalone.
      • Resolved: let’s put the “monthly” content back into this doc. ACTION: Ivar.
    • Resolved to get a sufficiently done version in 685 and then apply the proposed new specs. This is not an official endorsement of the inclusion of that new spec in EE11, but it’s useful to think about it now.
    • DONE: Arjan to take the discussion we did to day to the platform-dev list. Subject: platform-685: Wave discussion

Emily wants to have some plan of record for what we will do for the future releases when shipping CDI-lite in Jakarta Core Profile while Jakarta Web Profile needs to add the remaining part of CDI. This is for PR 139.

  • Current state
    • Core profile jar includes whole CDI
    • Web profile jar includes whole CDI
  • Desired future state
    • Core profile jar includes CDI lite
    • Web profile jar includes CDI lite and a jar that is the “rest of CDI”
  • Find a way forward:
    • Get OpenWebBeans to agree to clean separation between CDI lite and the rest of CDI.
    • Then we would have Red Hat and OpenWebBeans on board for this blocking issue.
    • Jan: The regular cadence idea makes it more possible to make progress on this.
    • **See https://github.com/jakartaee/cdi/issues/640 **

API Bug Fix PRs:

  • https://github.com/jakartaee/jakartaee-api/pull/139
  • https://github.com/jakartaee/jakartaee-api/pull/96
  • 10.x patch release (10.0.x) or wait for 11?
    • Emily: This could also be done as a “preview” release toward EE 11.
      • This would have the benefit of not requiring the full compatibility and certification process.
      • This is a good way to encourage another spec to be more proactive in development.
  • What about a patch release? A patch release is less than a minor release.
    • This is mainly about security, CVEs

Back to the top