Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

General Date: 2019-11-26

Present:

  • Kevin Sutter (IBM)
  • Ivar Grimstad (Eclipse Foundation)
  • Tanja Obradovic (Eclipsed Foundation)
  • Scott Stark (Red Hat)
  • Jonathan Gallimore, Cesar Hernandez (Tomitribe)
  • Ed Bratt, Bill Shannon (Oracle)
  • Steve Millidge (Payara)
  • Martin Stefanko (Red Hat)
  • Kenji Kazumura (Fujitsu)
  • Carlos Andres De La Rosa (Eclipse Committer)
  • Brian Stansberry (Red Hat)
  • Andy Guibert (IBM)
  • Edwin Amoakwa

Agenda

[KWS] Java SE 8 or Java SE 11 as the minimum.

Another key decision to allow for continued development efforts.

  • [KWS] Will need to propose a vote on the mailing list indicating the recommendation of Java SE 8 as the minimum, but we would support both Java SE 8 and 11. (Steve “volunteered” to post the vote.)

Deferred to next meeting

Versioning due to javax.* -> jakarta.*

[KWS] Does the package rename from javax.* to jakarta.* require a major version update for each component spec? For example, does CDI 2.x have to do a 3.0 release when doing the move to the jakarta.* namespace?

https://www.eclipse.org/lists/jakartaee-platform-dev/msg00862.html

Two areas to discuss (at least):

  • Semantic versioning at the Spec level (ie. JPA 2.x - > 3.0)
  • Semantic versioning at the Package level (do we need to start over at 1.0?)

Conclusion from mailing list discussion:

  • Semantic versioning at the Spec level (ie. JPA 2.x -> 3.0)
  • Semantic versioning at the Package level (OSGI) (ie. jakarta.persistence at 3.0)

The package level versioning is recommended, not specified.

[IG] Decide which specifications to prune

Vote: https://www.eclipse.org/lists/jakartaee-platform-dev/msg00838.html

Pruning Vote +1 Steve Millidge +1 Werner Keil +1 Ivar Grimstad +1 Bill Shannon -1 Kenji Kazumura +1 Kevin Sutter +1 Scott Stark

Kenji added further breakdown of the -1

  • Jakarta XML Registries JSR 93 -> +1
  • Jakarta XML RPC JSR 101 -> +1
  • Jakarta Deployment JSR 88 -> +1
  • Jakarta Management JSR 77 -> +1
  • Jakarta Enterprise Bean entity beans -> +1
  • Jakarta Enterprise Bean interoperability -> -1
  • Jakarta Enterprise Bean 2.x and 1.x client view -> -1
  • Jakarta Enterprise Web Services JSR 109 -> -1

The EJB specs with -1 above are optional in Jakarta EE 8. JSR 109 was not previously marked optional.

[IG] Decide which specifications to add

Vote: https://www.eclipse.org/lists/jakartaee-platform-dev/msg00839.html

Adding Vote +1 Steve Millidge +1 Werner Keil +1 Ivar Grimstad +1 Bill Shannon +1 Kenji Kazumura -1 Kevin Sutter -1 Scott Stark

Discussed how to handle -1 votes on add/prune topics above. Should we vote on the specs individually? Or group by technology (the SOAP support as a group).

DECISON: Decisions will be made with majority votes. Unanimous is not needed.

[SM] What should our approach be to obtaining a date from dependent projects?

(Kevin has put a request to all the spec projects for a date)

[KWS] Determine a dependency graph for the remaining projects and work out a spreadsheet (or some doc) of all of the pieces of required work.

[KWS] Specification Sizing Exercise

https://docs.google.com/spreadsheets/d/1EN5UEzxFV1Buk7yqdQAweaynWJ3UNn2BjN7blXn9vh4/edit#gid=0

We need a target date for the specifications to be ready several weeks before the target end date. Using milestone releases will solve the issue of artifacts timing out in the OSSRH staging repository.

Discussed which implementation will be the first compatible implementation. The optional aspects may “force” this to be Eclipse GlassFish. That means that we will need a release plan for Eclipse GlassFish in order to create a plan for Jakarta EE 9.

[SM] What tasks do we need to do at the platform level for the release?

Discuss on the mailing list.

If we can create such a list, it can be used for the component specs to estimate when they will be able to deliver.

Deferred to next meeting

Back to the top