Date: 2024-12-10
Present:
- James Perkins (Red Hat)
- John Clingan (Red Hat)
- Ed Burns (Microsoft)
- Jared Anderson (IBM)
- Kyle Aure (IBM)
- Emily Jiang (IBM)
- Anand NK (IBM)
- Nathan Rauh (IBM)
- Tom Watson (IBM)
- Petr Aubrecht (Payara)
- Arjan Tijms (OmniFish)
- Jan Westerkamp (iJUG)
- Gurunandan Rao(Oracle)
- Scott Stark (Red Hat)
- Scott Marlow (Red Hat)
- Ed Bratt (Oracle)
Agenda and Minutes
Top of mind for Ed, Arjan, Jared
- No meeting on 2024-12-24, 2024-12-31.
- First meeting in CY2025 will be 2025-01-07.
- BALLOT for excluding tests:
private void addBeanForMetamodel(AfterBeanDiscovery afterBeanDiscovery, PersistenceUnitDescriptor descriptor) {
addQualifiedBean(afterBeanDiscovery, descriptor, Metamodel.class)
.scope(Dependent.class)
.createWith(e -> getEntityManagerFactory(descriptor).getMetamodel());
}
private EntityManagerFactory getEntityManagerFactory(PersistenceUnitDescriptor descriptor) {
return CDI.current().select(
EntityManagerFactory.class,
descriptor.getQualifiers()
.stream()
.map(e -> createAnnotationInstance(loadClass(e)))
.toArray(Annotation[]::new))
.get();
}
- Strategy for putting Web Profile to ballot in CY25Q1, separately from Platform Profile
- The Platform Project requests the Platform TCK project to give top priority to getting the Web Profile tests passing.
- It looks like we will not be able to bring the Web Profile to ballot in CY2024. However, it is still useful to focus on Web Profile, bring it to ballot, and then do Platform Profile.
- Besides passing all Web Profile tests, the long pole remaining is getting in the Persistence CDI integration tests as documented in issue 1405.
- Scott Stark and Scott Marlow
- Has agreed to shift focus to resolve the issues blocking the completion of Web Profile tests passing GlassFish 8.0 JDK 17.
- Ed asked for a swag estimate for doing this.
- Scott enumerated three big tasks:
- 1. Get the remaining tests passing.
- Approximately 206 Persistence non platform test failures to resolve
- TCK call will look at the full set of Web Profile tests that are remaining to be passed.
- ACTION: Ed to obtain concrete estimate and update dashboard: https://github.com/orgs/jakartaee/projects/12/views/1
- 2. Produce, for the first time ever, a separate independent Web Profile TCK distribution.
- 3. Create the CCR for GlassFish for the Web Profile using the CI jobs.
- Arjan listed the jobs
- Core Profile
- Because Core Profile did pass its ballot, Ed suggests releasing the artifacts to Maven central. If changes become necessary, we will do service releases, as usual.
- For example, WebProfile API maven artifact will publish with version 11.0.0, but could be with a jakartaee-api-parent version of 11.0.1
- ACTION: Scott Stark to apply changes from Andrew Pielage in https://github.com/jakartaee/specifications/pull/782#discussion_r1872825250 and then we can release the artifacts.
Refactoring progress report
Jakarta EE 11
- Authentication 3.1.1 TCK update
- Two new challenges opened with proposed PRs attached
- Servlet 6.1.1 TCK update
- Latest staged version is from Oct 31
- What is the status of getting a newer staged version with the revert done?
- ACTION: Ed and Jared to sync offline to understand the job to be done.
- Validation 3.1 API
- Hearing that the Validation implementation cannot go final until some files are added / updated in the API jar.
- When will we get a new 3.1.1 release of the API?
- ACTION: Jared, please clarify the job to be done.
Jakarta EE 12
- DISCUSS proposal to decouple “JDK-update” releases from feature releases in two separate release trains
- Train 1: Just whatever necessary to pass on JDK x
- Train 1 would be released e.g. 6 months after “an LTS release of Java SE”
- Is this just a service release of the currently available TCKs, or does it require a minor release of the specs and TCKs? We have done the former in the past.
- Train 2: New features
- Train 2 would be released between the train 1 releases, e.g one year after
- [Jan] Requirement to extract Component Spec related tests from the Platform TCK to the Component Spec itself (except integration tests, that would otherwise create new dependencies besides the API and Spec document itself directly or transitively - they should stay in the Platform TCK project and/or in the related project).