Skip to main content
Breadcrumbs
Date: 2023-06-20
Present:
- Jan Westerkamp (iJUG)
- Lenny Primak (Individual)
- David Matejcek (OmniFish)
- Arjan Tijms (OmniFish)
- Ed Burns (MSFT)
- Ivar Grimstad (Eclipse Foundation)
- Jared Anderson (IBM)
- Scott Stark (Red Hat)
- Lukas Jungmann (Oracle)
- Dmitry Kornilov (Oracle)
- Petr Aubrecht (Payara)
- Fanon Jupkwo (Individual)
- Jesse McConnell (Webtide)
- Cesar Hernández (Tomitribe)
- Brian Stansberry (Red Hat)
- Maximilian Arruda (Individual)
Agenda and Minutes
Practical
- Resolved: Ed and Arjan to alternate weeks running this meeting, starting this week.
ACTION: Getting all specs through Plan Review
- https://github.com/jakartaee/jakartaee-platform/issues/681
- Plan Review PRs: https://github.com/jakartaee/specifications/pulls?q=is%3Apr+is%3Aopen+label%3A%22plan+review%22
- In Progress: Ed to compare query list with responses from spreadsheet
- Ed to explore who can run Jakarta Validation for EE 11, with a view toward adding one feature: how to do validation of Java records.
- Jan TCK is referencing incorrect versions. That needs to be cleaned up.
- Scot looked at the issue, but no major progress yet.
- Electing new project lead
- Gunnar no longer available for Jakarta Validation - doesn’t work for Red Hat anymore.
- ACTION: Ivar to do a “pmc follow up” to the existing validation list.
- Jakarta Expression interested in records
- Jakarta Persistence interested in records (?)
- Actually doesn’t make sense
- 2 or 3 where it makes sense
- Embeddables
- ID class
- JPQL (maybe) -> select new … -> create record
- Already works, mostly, but needs to be in the spec
- MIGHT work for Hibernate, but not OpenJPA etc
- XML Binding could potentially use records
- No update planned for 11
- Can be done in implementation first
- JAXB RI is still called “[tech] RI” which was a theme in EE 10 to rename
- ACTION: rename “JAXB RI” to something else (like Angus Mail etc) (priority: low, if time allows)
- JSON Binding implementation already support records
- JavaBean pattern required first
- The word “record” is not in the spec
- Type conversion
- Jakarta Converter API
- NO time on now, but might be in scope for 12
- Maybe incubator
- ACTION: Advise spec leads -> doing records, ask yourself here is how the conversion aspect works. Capture it.
- Lack of conversion spec is indeed troublesome
- How does Spring do it?
- We might have a record theme of some kind
- How does Spring handle records in their persistence layer?
- Do they add anything in Spring Data?
- Version 6 -> use JDK 17, so more able
- https://github.com/jakartaee/validation-spec/issues/267
- Rename of Jakarta Bean Validation to Jakarta Validation
- Jared discovered that Persistence was missing. Lukas had committed to having it in. Arjan to contact Lukas.
- Release Review template. Please change it to Plan Review template.
- Some PRs need to be updated to use plan review
- Templates are in spec root github
- Need Jakarta Interceptors 2.2 Release
- Dependency Injection (DI) might be folded into CDI too.
- Common annotations
- Some annotations should maybe not be there, but still convenient for Spring, Shiro, etc
ACTION: Get Jakarta EE 11 Release Plan DRAFT (source link) beyond DRAFT state
- EE11 labeled issues
- Wave discussion: see https://github.com/jakartaee/jakartaee-platform/issues/685
- Discussion about non-binary dependencies
- Jakarta REST does have a non-binary (behavioral, or integration) dependency on Servlet. For example, impact of ServletContainerInitializer.
- JSF ExternalContext has dependencies on Servlet and Portlet.
- Agreement that the wave discussion does need to take those into account.
- Jan suggested we explore some ways to quantify these non-binary (behavioral or integration) dependencies.
- Spec documents declare their usage of APIs in a universal way.
- Current spec documents might not say (or care) about specific versions here.
- Optional API dependency in pom.xml could be a relatively simple solution
- Pom.xml is a **non-normative **artifact -> the pom dependency and the API artifact is the technical contract
- Maven 4 -> the build pom, and the consumer pom
- Module-info.java -> EE 9 should java, EE 10 it HAS to be there.
- All dependencies must be there at compile time
- ACTION: test if module-info.java can be used to express non-binary dependencies. JAN will take a look at this.
- This relates to the extent to which the api jar is a part of the specification or not.
- Another dimension of complexity is the TCK interdependencies.
- Agreement that we take the current state of the Wave discussion and move it on.
- Ed asked how did we address this in < EE11?
- Scott mentioned there was some level of hand-waving. But in 11, actually making solid progress on this interdependencies is a goal of 11.
- Emily and Lenny asked how much effort are we willing to put on this particular effort in 11?
- Jan brought up again the goal of compliance with JPMS. At least in the core profile first. We need to be sure about Wave 0, 1, 2. The others we can solve later.
- Nathan brought up the question of what about the proposed new specs?
- ACTION: Ed to kick off discussion on new-to-EE11 specs on platform-dev. These notes are meant to capture the dimensions of discussion.
- See “monthly” from 2023-06-06.
- Jakarta NoSQL
- Marlow: Last week, we asked some Jakarta NoSQL questions, https://www.eclipse.org/lists/nosql-dev/msg00232.html has answers to these and related questions.
- The absence of a clean JDBC style driver concept and platform spec integration is a problem. This would argue for keeping it standalone.
- Resolved: let’s put the “monthly” content back into this doc. ACTION: Ivar.
- Resolved to get a sufficiently done version in 685 and then apply the proposed new specs. This is not an official endorsement of the inclusion of that new spec in EE11, but it’s useful to think about it now.
- DONE: Arjan to take the discussion we did to day to the platform-dev list. Subject: platform-685: Wave discussion
Emily wants to have some plan of record for what we will do for the future releases when shipping CDI-lite in Jakarta Core Profile while Jakarta Web Profile needs to add the remaining part of CDI. This is for PR 139.
- Current state
- Core profile jar includes whole CDI
- Web profile jar includes whole CDI
- Desired future state
- Core profile jar includes CDI lite
- Web profile jar includes CDI lite and a jar that is the “rest of CDI”
- Find a way forward:
- Get OpenWebBeans to agree to clean separation between CDI lite and the rest of CDI.
- Then we would have Red Hat and OpenWebBeans on board for this blocking issue.
- Jan: The regular cadence idea makes it more possible to make progress on this.
- **See https://github.com/jakartaee/cdi/issues/640 **
- NOTE:
- Are all vendor reps in agreement that this needs to be done?
- ACTION(?): have a vote on this?
API Bug Fix PRs:
Project management software selection
- Ed has been unable to get traction with GitHub Projects and Issues. He’ll continue to pursue getting traction.
- ACTION: in the meantime, Ed seeks approval to set up Azure DevOps Boards public instance jakarta-ee-azdo **for the purpose of helping Ed and Arjan improve the quality of their project management. **Let’s try it and see if it helps.
- ACTION: Ed to file gitlab ticket to get the AzDO Boards extension installed in https://github.com/jakartaee/jakartaee-platform for starters and connected to this **jakarta-ee-azdo **instance. If this works well, we can do the same thing for
- https://github.com/jakartaee/jakartaee-api
- https://github.com/jakartaee/specifications
- https://github.com/jakartaee/jakarta.ee
- and any other issue trackers we need.
Back to the top
