Date: 2021-11-09
Present:
- Jean-Louis Monteiro (Tomitribe)
- Werner Keil (Committer, Ambassador)
- Tomas Langer (Oracle)
- Jan Westerkamp (iJUG)
- BJ Hargrave (IBM)
- John Clingan (Red Hat)
- Dmitry Kornilov (Oracle)
- Brian Stansberry (Red Hat)
- Scott Kurz (IBM)
- Scott Stark (Red Hat)
- Ivar Grimstad (Eclipse Foundation)
- Scott Marlow (Red Hat)
- Thomas Watson (IBM)
- Kevin Sutter (IBM)
- Emily Jiang (IBM)
- Roberto Cortez (Red Hat)
- Kenji Kazumura (Fujitsu)
- Lukas Jungmann (Oracle)
- Rudy De Busscher (Payara)
- Ed Bratt (Oracle)
- Petr Aubrecht (Payara)
- Cesar Hernandez (Tomitribe)
Agenda and Minutes
Jakarta EE 10 Status (standing agenda item)
- Still need interceptors release.
- https://projects.eclipse.org/projects/ee4j.interceptors/who
- https://ci.eclipse.org/interceptors/job/1_interceptors-build-and-stage/configure - needs to update the JDK to 11 to build
- Bean Validation 3.0.1 service release done
- CDI, EJB, Transactions waiting on Interceptors
- https://github.com/eclipse-ee4j/jakartaee-platform/wiki/JPMS_Naming_Rules
- This table should be added to the platform specification
- https://github.com/eclipse-ee4j/jakartaee-platform/wiki/Adding-Release-Notifications
- May need to remind projects about this at a later point
- https://projects.eclipse.org/projects/ee4j.ca/releases/2.1 approved
have 2.1.0-B1 release
- Requirements for separated TCKs proposal in discussion
- These need to be explicitly listed in the platform specification / TCK documentation
- How will tests that are added to refactored-out test suites be added back into the platform TCK?
- Action: Have the proposal ready for the next platform call
Project Proposal for Jakarta Commons
- https://docs.google.com/document/d/19eN3pQxtoMNoiqEKasPzbuTjUcYBC4pS0TGT12lVE3Y/edit
- Tomas Langer gave an overview of the proposal
- Discussion
- Produce multiple JARs to avoid a single “root” dependency for all specifications
- Would also result in multiple JPMS modules
- How to avoid it being a “dumping ground” for everything that doesn’t fit elsewhere?
- Will need strict control and “high cost of entry” to avoid it becoming the tail that wags the dog
- All specs would be required to be on the latest version
- Pro: reuse. Con: less flexibility to change the common stuff
- Will bring order and common architecture to the platform
- Consistency across specifications
- Could this be a library project? Or should it be a specification?
- If vendors may want to implement their own version e.g. for performance reasons, then a TCK is needed and it should be a proper specification
— The following items were not discussed due to time constraints —
Priority discussion and proposal
- https://www.eclipse.org/lists/jakartaee-platform-dev/msg02928.html
- https://docs.google.com/document/d/15MM8tX1sS_i5OacrgZZPmkT8WVamQkkziLChVVopOPw/edit#heading=h.639yzy373xzf
CDI Integration
- https://www.eclipse.org/lists/jakartabatch-dev/msg00226.html
