Date: 2023-11-07
Present (please put your name down here to mark yourself as present…):
- Scott Stark (Red Hat) Absent, unable to attend today
- Ed Burns (MSFT)
- John Clingan (Red Hat)
- Ivar Grimstad (Eclipse Foundation)
- Jared Anderson (IBM)
- Emily Jiang (IBM)
- Jim Krueger (IBM)
- Nathan Rauh (IBM)
- Thomas Watson (IBM)
- Adam Yoho (IBM)
- Jan Westerkamp (iJUG)
- Arjan Tijms (OmniFish)
- Kenji Kazumura (Fujitsu)
- Petr Aubrecht (Payara)
- David Matejcek (OmniFish)
- Brian Stansberry (Red Hat)
- Scott Marlow (Red Hat)
- Majid Mostafavi
- Cesar Hernandez (Tomitribe)
Agenda and Minutes
jakartaee-api default branch renamed from master to main
- An example of the new self-service: https://github.com/jakartaee/.eclipsefdn/pull/1
- Is there a technical benefit?
- Whatever the original reasons, it’s the new default now for GitHub
- MicroProfile
- Everything renamed by Emilly
- No problems observed
Housekeeping
- Arjan to run the meeting Nov 7, 14, 21, and 28
- Status?
- Jakarta Persistence injection of EntityManager
- See https://www.eclipse.org/lists/jpa-dev/msg00191.html
- See https://github.com/jakartaee/persistence/pull/460
- Where to put the tests if the spec is simply supporting CDI (as opposed to being based on CDI)?
- In the CDI EE integration spec?
- Alternative (and preferred future?): The integration tests could be placed in an optional TCK module for component specs not already depend on CDI
- Jakarta Persistence merely supports CDI (does not depend on it)
- EntityListeners are injectable by CDI
- Spring uses Jakarta Persistence, and persistence being dependent on CDI would be hard for them and/or break things. Same for Tomcat/Jetty.
- Do (some) Jakarta EE spec teams want to be SE only (and have EE somewhere else)?
- Some came from the JDK. They are not all EE focussed.
- Have tests that are only needed for EE certifications separate.
- Servlets becoming CDI beans
Some projects have few or no committers or leads missing
Status of CDI restructuring
- Created GitHub milestone to track those that have already been published to maven central
- Others that have a maven artifact jea-234.
- cdi, cdi-el, lang-model have Alpha1 for API and up to Alpha5 for TCK
- interceptor has RC1
- persistence has B01
- Other that DO NOT have a maven artifact yet
- I’d like to get clarity on whether or not we attempt this in EE 11. My gut instinct right now is:
no. maybe.
- The group discussed several aspects.
- The “override” case (if the vendor does not like the defaults)
- Platform defines the WebProfile interface, as in this proposal.
- This interface has a “lineup” of all the versions of all the specs in that platform.
- What about if an impl of a component spec wants to override?
- Do we need to consider this corner case?
- If so, isn’t this a kind of “config”, and if so, shouldn’t we be looking at this as Jakarta Config?
- What about the good old fashioned “Service Loader” technique?
- CDI and JSON specs currently use this.
- Dmitry gave an update on Config: Not available for use in EE11.
- Ed polled the group on the utility of the idea in general.
- Arjan and Nathan shared concrete examples for doing this.
- We would need to add TCK
- Platform TCK
- Web Profile TCK
- Core Profile TCK
Spec lead election for Jakarta Validation should happen asap.
Social sharing:
