Vote 2 to leave Activation in javax namespace (split with no clear majority)
Vote 3 to leave JAXB, JAX-WS, SOAP, and WS Metadata in javax namespace (split with no clear majority)
Vote 4 to make Enterprise Web Services and EJB 2.x API Group as optional (majority voted +1)
Vote 5 to prune EJB Interop (Ch 10 of EJB 3.2 Core spec) (majority voted +1)
Proposed compromise to alleviate deadlock on Votes 2 and 3:
Move Activation, JAXB, JAX-WS, SOAP, and WS Metadata to jakarta namespace
Activation would be a Required spec for the Platform due to multiple dependencies
JAXB, JAX-WS, SOAP, and WS Metadata would become Optional specs for the Platform
DECISION: Go with this compromise and communicate via the Release Plan.
[KWS] Java SE 8 or Java SE 11 as the minimum.
Another key decision to allow for continued development efforts.
[SM] Will track as part of the Jakarta EE 9 Release Plan. Proposed wording for the Release Plan: “For inclusion in Jakarta EE 9, specification’s apis MUST be compiled at the Java SE 8 source level. However, compatible implementations of the Jakarta EE 9 Web Profile and Full Profile WON’T be required to support Java SE 8 and may certify compatibility on Java SE 11 and/or Java SE 8. ”
Updated Statement:“For inclusion in Jakarta EE 9, specification’s apis MUST be compiled at the Java SE 8 source level. However, compatible implementations of the Jakarta EE 9 Web Profile and Full Profile will be required to certify compatibility on Java SE 11. Compatible Implementations may additionally certify and support Java SE 8.”
Solid input via the spreadsheet, but still looking for more input…
Long pole items are the Compatible Implementations that are needed for each Specification version submission.
Emphasize use of RCs, especially for APIs. Allow 2 months time between RC and ready for Final ballot.
Promote early releases for the Component features (ie. JPA, JSON-B, etc). There is no requirement to wait for the Platform release.
RCs at the Platform level is a good idea, but it will affect the final schedules.
Also need to be aware of the IDE’s plans to support Jakarta EE 9. Timelines, etc. Having RCs available early will help with their efforts as well.
When will Glassfish be available as the Platform Compatible Implementation? Steve and friends at Eclipse Glassfish will have to determine some date to shoot for.
Update Release Plan and make it publicly available by Thursday, Dec 12.
[KWS] Other minutes…
Need to update the Release Plan per the discussions today.
Make Release Plan more publicly accessible.
Announce on Platform dev list by Thursday, Dec 12
Discuss the Release Plan at next week’s meeting.
Hopefully, finalize Plan for submission to Steering Committee.
Didn’t get to the other items below…
[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.
[IG] Can we exclude optional parts of the component specifications in the platform specification(s)
Releasing the platform spec requires TCK passed by an implementation, including optional parts. Eclipse GlassFish will most likely be the only implementation of the optional parts as no vendors are likely to include them in their implementations.
Exclude optional parts from the platform specification
Optional parts are still part of the component specifications and will be implemented and tested there