Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2022-09-06

Present (please put your name down here to mark yourself as present…):

  • Jared Anderson (IBM)
  • Emily Jiang (IBM)
  • Jim Krueger (IBM)
  • Nathan Rauh (IBM)
  • Scott Marlow (Red Hat)
  • Petr Aubrecht (Payara)
  • Arjan Tijms (OmniFish)
  • Dmitry Kornilov (Oracle)
  • Cesar Hernández (Tomitribe)
  • Scott Stark (Red Hat)
  • Nathan Erwin (Individual)
  • Ryan Cuprak (Jakarta EE Ambassadors)
  • BJ Hargrave (IBM)
  • David Matejcek (OmniFish)
  • Lukas Jungmann (Oracle)
  • Werner Keil (Committer, Jakarta EE Ambassadors)
  • Brian Stansberry (Red Hat)
  • Ivar Grimstad (Eclipse Foundation)

Agenda and Minutes

Jakarta EE 10 Ballot status (one week left)

  • Platform: 7
  • Web: 4
  • Please vote asap - Jakarta EE working group members

Versioning of XML Schemas

  • Should XML schemas always follow the spec version? Example: Jakarta Persistence 3.1 (only change would be the version number and the file name)
    • It would be nice as it is consistent with others
    • Cost is too high
    • If EE 11 contains JPA 4.0, it might be a good target
    • For major update, we always update the schema version
    • For minor update, we don’t require it unless required
    • Small print: Even whitespace changes in schema, it will also require schema version update
    • Conclusion: not do this due to the big cost. If anyone has objections, please raise it for this to be discussed again.

Retrospective

  • What we have done well
    • We produced Jakarta EE 10 with function updates.
    • Great platform call to discuss technical issues
    • Removed deprecated APIs - 4 or 5 specs have done this (CDI, faces, etc). In the past, we have never removed APIs or methods
    • Also made some technologies optional
    • Updated some TCKS to use new technologies
    • Introduction of new core profile
    • Did not cut the corners - for Platform and Web Profile, we did not rush them
    • Thank you Scott Marlow and Scott Stark for handling Jakarta EE 10 releases
    • Wider communities contributions
    • No single dominant person.
    • Thank you Arjan for your great contribution in many areas
  • What we need to improve
    • 4 month delay on original planned date to when we actually completed.
    • When a component spec final version or service release is created, the dependencies are not consistently updated with other specs that depend on it, for instance, stop using RC version dependency.
    • Did not add any new component specs to the platform
    • Moving a component spec from platform to a profile did not go well.
    • It is difficult to change tests in a service release when not changing what is being tested, but improving the test. - PROCESS
    • We need a better project management board/entry point
    • Jakarta EE needs architecture committee to see overall picture and advise how individual specs evolve
      • Spec evolve in isolation could break each other
    • **Still have too much bureaucracy in the process. Process is still complicated. **
      • How to simplify the process
      • How to automate the process
      • Send emails to different parties.
      • The process assumes one person/team works on one spec. There is a lot of repetition going on.
    • Documenting how to run TCKs needs improvement
    • Use issue tracker more efficiently - raise an issue and then discuss here
    • Staged SPEC API artifacts are not available to community projects, need to release staged SPEC API artifacts to Maven Central also.
    • Individual specs sometimes do not release Milestone releases
    • JAX-RS wants to rename packages, no one was willing to update
    • No procedure on how release candidates are to be produced
    • Some standalone TCKs cannot be executed easily.
  • Actions
    • More work on TCKs to modernize
    • One single location - what people expect Jakarta EE 11?
    • Unforeseeable event occurs
    • Take what was learned from the unforeseeable events and improve the process to include those things that we found needed to be done at the end of the release and plan for it.
    • Look to simplify and automate processes (long list for the PR)
    • Make platform call more structured - one section to focus on architecture discussion; invite spec committers to attend the call
    • Raise an issue for spec interaction for an example
    • When moving specs from platform->web profile or web profile -> core profile, more thoughts need to be put, especially TCKs.
    • In the future EE release, we should maintain Project management board
    • If someone works on an issue, put a comment to tell others so that no dup work would incur.
    • No documentation on how to release, when to push to maven central.
    • Spec process: simplify the process - PROCESS
    • Specs should release milestone releases in maven central

— did not get to the items below —

Base Requirements for Jakarta EE 11

  • Security Manager
  • Java SE version

Back to the top