| [jakarta.ee-spec.committee] Review for approval: Spec Committee Meeting Minutes July 17th, 2019 |
Attendees (present in bold):
Kenji Kazumura - Fujitsu, Michael DeNicola
Dan Bandera - IBM, Kevin Sutter, Alasdair Nottingham, BJ Hargrave
Bill Shannon - Oracle, Ed Bratt, Dmitry Kornilov, Will Lyons
Steve Millidge - Payara, Arjan Tijms
Scott Stark - Red Hat, Mark Little, Antoine Sabot-Durand
David Blevins - Tomitribe, Richard Monson-Haefel, Jean-Louis Monterio
Ivar Grimstad - PMC Representative
Alex Theedom - Participant Member
Werner Keil - Committer Member
Eclipse Foundation: Wayne Beaton, Tanja Obradovic, Paul Buck, Mike Milinkovich
Past business / action items
Minutes from July 3rd meeting - Approved
Minutes from July 10th meeting - Approved
Jakarta EE 8:
JESP operations and associated spec committee PR request template, unresolved issues:
A convention for the downloads.eclipse.org directory naming conventions for a spec project. Bill proposed:
ee4j/<project>/<project>-tck/<project>-tck-eftl/staged/
ee4j/<project>/<project>-tck/<project>-tck-eftl/release/
ee4j/<project>/<project>-tck/<project>-tck-epl/
Or
ee4j/<project>/tck/eftl/staged/
ee4j/<project>/tck/eftl/release/
ee4j/<project>/tck/epl/
Or
Action: Proposals to be written up with options to be discussed in email and decided on in the next call (if required). Authors of each option to provide the advantages of their proposal.
How the proposed EFTL TCK is presented in the spec project release review. I guess we should just add a checkbox for the link to the staged binary.
How compatible implementations host TCK results in general. I don’t think we have anything to say on this other than how validated certification requests are promoted to jakarta.ee
How EE4J projects host TCK results. Is it sufficient to define a template for github releases?
How spec project release reviews indicate that there is at least one compatible implementation. Let’s resolve that on the other thread “where to publish TCK results”.
Discussion on TCK results ensued, a vote was held to decide on where TCK results need to be stored.
Vote: The testing results from the testing the candidate compatible open source implementation will be stored by reference or value?
Fujitsu- Ref
IBM - Ref
Oracle - Ref
Payara - Value
Red Hat - Ref
Tomitribe - Ref
Alex Theedom - Participant Member - Ref
Ivar Grimstad - PMC Representative
Werner Keil - Committer Member
Decision: By Reference
The topics that follow were not discussed in the July 17th call.
Webdev has created a pull request with a solution for publishing the specifications repository contents on the website (issue)
Jakarta Bean Validation and Jakarta CDI projects have been created, initial contributions are in the hands of the Eclipse IP Team (we anticipate the IP Team approval to move the content into an EE4J repository on July 17)
Arjan has asked that we change the name of the newly created “Jakarta Server Faces” project to “Jakarta Faces”. Under normal circumstances--assuming that there are no trademark implications(which I believe is true in this case)--for a project that we’ve just created, we’d just let them change the name. Does the Specification Committee believe that any ceremony (other than informing the community) is required?
How to deal with @since tags when updating the javadoc. Latest recommendation is to leave the acronyms in use and change to use the Jakarata spec short name as new tags are added.
Revise the Jakarta EE 8 Release Schedule
Jakarta EE 8 Livestream call for panel participation
Roadmap: Namespace: javax to jakarta - Big-bang or incremental [Discussion]
Process: Publish the fully approved JESP 1.2 (pull request)