Jakarta EE Platform Call

General Date: 2019-11-19

Present:

• Ivar Grimstad (Eclipse Foundation)
• Edwin Derks (Ordina)
• Kevin Sutter (IBM)
• Carlos Andres De La Rosa (Eclipse committer)
• Andy Guibert (IBM)
• Andy McCright (IBM)
• Josh Juneau (Independent)
• Paul Nicolucci (IBM)
• BJ Hargrave (IBM)
• Steve Millidge (Payara)
• Tanja Obradovic (Eclipse Foundation)
• Rhuan Rocha (Red Hat)
• Kenji Kazumura (Fujitsu)
• Martin Stefanko (Red Hat)
• David Blevins (Tomitribe)
• Jonathan Gallimore (Tomitribe)
• Bill Shannon (Oracle)

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.)

[IG] “Jakartify” the specification documents.

Status

DECISION: Optional, but strongly encouraged to Jakarta-ize the applicable specs as part of the Jakarta EE 9 effort.

[IG] Decide which specifications to prune

Prune Vote

Let the votes run until next meeting

[IG] Decide which specifications to add

Add Vote

Let the votes run until next meeting

[KWS] Backwards compatibility discussion.

When did we decide that the common open-source implementation is not the path to pursue? It seems that we have decided for each implementation to create their own solution? Related question – should Java EE 8 applications run on a Jakarta EE 9 app server? We need to nail down this backward compatibility statement(s) for Jakarta EE 9.

DECISION: The specification will not require backward compatibility. It is up to the implementations to do so if wanted. This allows new implementations to enter the market easier.

DECISION: It is okay to remove methods and/or update schema definitions that are in support of the pruned technologies. Not otherwise, e.g. general cleanup.

[TO] Tanja to find out a list of committers on the Jakarta EE Platform Project and invite them to sign up to the platform project mailing list - look here

DONE: Everyone on the mailing list now.

[KWS] Related to the previous bullet, do we have the proper representation on the Platform project (committers)?

Mail Thread

We should encourage additional participation and submit new committers as they have shown an interest and ability to participate. There should be no “free passes” to get on the committer list. Tomitribe, Payara, and Fujitsu should consider adding additional committers on the Platform project.

DECISION We’ll leave the Committer voting as-is until or if it becomes an issue, then we can address it.

[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.

Next meeting

[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?

Mail Thread

To be continued at next meeting. Two areas to discuss (at least):

• Semantic versioning at the Spec level (ie. CDI 2.x - > 3.0)
• Semantic versioning at the Package level (ie. jakarta.persistence.* is now at 1.0)

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

Next meeting

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

Next meeting

[IG] Related to the two bullets above: What steps/tasks are needed for a component spec to do the namespace switch? If we can create such a list, it can be used for the component specs to estimate when they will be able to deliver.

Next meeting