Skip to main content

Jakarta EE Platform Call

Date: 2021-06-29

Present:

  • Jean-Louis Monteiro (Tomitribe)
  • Ivar Grimstad (Eclipse Foundation)
  • Jesse McConnell (Webtide)
  • Scott Marlow (Red Hat)
  • Jan Westerkamp (iJUG)
  • Cesar Hernandez (Tomitribe)
  • Roberto Cortez (Red Hat)
  • Kevin Sutter (IBM)
  • BJ Hargrave (IBM)
  • Kenji Kazumura (Fujitsu)
  • Dmitry Kornilov (Oracle)
  • Lukas Jungmann (Oracle)
  • Werner Keil (Committer)
  • Emily Jiang (IBM)
  • John Clingan (Red Hat)

Agenda and Minutes

Versioning Scheme

  • Proposals
    • https://docs.google.com/document/d/1ZQGEYSCN5eYtDjWOXAQqNin7iwLKHnQFEP73FDoQdbw/edit?ts=60b68f2e#
  • Survey V2
    • https://survey.sogosurvey.com/r/bfeaPr

Versioning Scheme Vote

(graphic as of June 22, 2021)

  • Discussion regarding semantic versioning
    • Do we need to distinguish between component specifications and profiles/platform?
    • Should the platform be a marketing version?
    • And the individual specifications semantically versioned?
  • Should we take one step back and
    1. Decide on time-based vs feature-based platform/profile release cadence
    2. Then decide on versioning scheme?
    3. Also, what about the relationship between the xxxProfile and Platform versions?
  • Continue discussion on mailing list and next call
    • Jan will provide an updated presentation to Scott Stark and Ivar for the shared drive
    • He will start the conversation on the mailing list. He offered to walk us through the presentation at our next meeting.

JPMS

  • Discussion Thread
    • https://www.eclipse.org/lists/jakartaee-platform-dev/msg02632.html
  • We should require a module-info for Jakarta EE 10
    • Individual component specs as well as the Platform
  • https://github.com/eclipse-ee4j/jakartaee-platform/issues/329#issuecomment-840710785
    • If we define all of these module-infos, they should be considered part of the respective API. And, thus, are the signature tests also affected?
  • Suggestion for EE 10
    • Each individual spec provides a module info following a specified set of conventions:
      • spec module name is jakarta.
      • spec provides JPMS module definition (reliance on automatic module name is not allowed)
      • spec updates provider lookup algorithm to include search on module-path (if applicable)
  • We will not provide a platform/profile level module for EE 10
    • Don’t want to set the expectation that implementations must support JPMS at this point
    • Implementations can still experiment with their own aggregator modules
  • Ivar will send the text above to the mailing list (jpms thread)

[Emily] Jakarta Annotation - who is leading the spec?

  • https://projects.eclipse.org/projects/ee4j.ca/who shows no project lead
  • CDI spec would like this spec to make some progress
    • Dmitry will review, and merge the PRs (leaving them open for a week for comments).
    • We encourage a volunteer to sign up for the project lead position (Scott Marlow tweeted a request)

Back to the top