Date: 2023-09-12
Present:
- Jan Westerkamp (iJUG)
- Jared Anderson (IBM)
- Nathan Rauh (IBM)
- Thomas Watson (IBM)
- Jean-Louis Monteiro (Tomitribe)
- Arjan Tijms (OmniFish)
- Petr Aubrecht (Payara)
- Ivar Grimstad (Eclipse Foundation)
- Ed Bratt (Oracle)
- John Clingan (Red Hat)
- Dmitry Kornilov (Oracle)
- Brian Stansberry (Red Hat)
- Cesar Hernandez (Tomitribe)
- Scott Stark (Red Hat)
- Kenji Kazumura (Fujitsu)
- Tanja Obradovic (Eclipse Foundation)
Agenda and Minutes
Ed Burns away this week, 2023-09-12.
- Arjan running meeting again
Appeal for review of following PRs:
https://github.com/jakartaee/validation/pull/185
- https://github.com/jakartaee/validation-tck/pull/192
- https://github.com/jakartaee/validation-spec/pull/270
- The substance of the change is essentially a global search and replace for “Jakarta Bean Validation” to “Jakarta Validation”. Each of the three repositories does still compile after the change.
- The required eclipse Restructuring Review has been requested under separate cover and is being tracked at https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3497 .
- We noticed again that we have multiple repos for some specs
- Jan suggests to merge into mono repo
- Ivar says it not the platforms task to decide or mandate this \
Working towards milestone for Jakarta EE 11
- M1
- Not all components implemented for a single EE product
- Loose collection of implementations?
- What’s the goal?
- Words in a document?
- API releases?
- Implementations?
- In MP - RC releases - that do implementations and TCKs
- Code first vs design by spec
- Milestone is step in some progress towards that specification
- Show progress
- Not big-banging (agility in development)
- Who are we making the milestone for?
- End-user to provide feedback
- Vendors / jakarta related bodies
- Timebox effort
- Ask the implementations - would you have something ready? What are you going to deliver
- Minimum bar
- API release and/or the spec document (depends on whether the project even has a spec document)
- Optional
- TCK
- Compatible implementations
- Release them all as usual (together)l, even if a document has no updates (yet)
- Release date of M1
- Depends on final release date of Jakarta EE 11 itself
- End of year? Just before JakartaOne Livestream?
- 5th December - ACTION: communicate date
- M2 should be there as well
- Perhaps release train for milestones? Every 2 months? 3 months?
- Some dependencies -> lower wave versions must support some Java version.
- Patch release for EE 10
- Does EE 11 Milestone interfere here?
- There are various things to be come
- Document / tag PRs for EE 10?
- Optional dependencies on CDI, like in Jakarta Transactions, currently not optional in JPMS module-info.java
- https://github.com/jakartaee/transactions/issues/214
- As it appears: not optional in the spec at the moment
- Revise for Jakarta EE 11?
- (Transactions refers to old CDI API version)
- Potentially put extension in separate API jar / module
- Ship has sailed for Transactions -> @Transactional is already in same package
- API self contained in Java SE environment
- Optional dependencies marked static
- For platform spec API not static
- The jakarta.jakartaee-api.jar does NOT have module-info.java
- The next release (EE 11) will not be a jar with classes
- It will only be a pom, transitively depending on individual spec jars
- Do we need to strictly (more strictly?) specify that the CDI extensions are optional in the Jakarta Transaction specification
- What is the difference between a static dependency and a “regular” dependency in module-info.java? Why not make everything static?
- See https://jakarta.ee/specifications/transactions/2.0/jakarta-transactions-spec-2.0#transactional-annotation
- Alternative options
- CDI is more and more central - prepare to pull it on. Don’t try to be independent of CDI
- An implementation / spec that’s completely independent of CDI, doesn’t need it, doesn’t use it. But there’s an extra feature / extension providing extra options within a CDI environment.
- Servlet is another example
- Tomcat used standalone and with Spring
- Dependency on CDI therefore pretty much must be optional
- For most other specs CDI should (must) be mandatory
- Mojarra uses CDI internally as well, Jersey used HK2 internally
- Extra complications when used with other DI environments
- JPMS - questions for them being required or not
- What guarantees, if any?
- Should we add it more strictly into the spec?
- Require module-info.java to be present
- We don’t test them
- If vendor wants to produce their own artefacts they can
- Jakarta EE specification project API artefacts are there for convenience - not normative
- Would users (consumers) have issues with portability if module-info.java is missing or different (non-portable)
- Do users ever use JPMS? Do client modularized applications even exist?
- Binary compatibility might not be influenced here - compilation matters, and then they must compile against an API artefact with JPMS, but the produced war should run across implementations from different vendors
- Reproducible builds
* API
- Can someone share their analysis of how the spec committee is responding to our proposed plan? I am a guest on the spec committee, so my analysis is only observational.
- Concerns from Red Hat about Jakarta Data itself?
- https://twitter.com/1ovthafew/status/1696503099601383739
- Jan TCK dependency to Jakarta NoSQL need to be handled
- Lenny observes the need to explain to our users the difference between the use cases of Data and Persistence.
- Where?
- Tutorial?
- Blog post?
- Vendor documentation?
- YouTube videos?
- Conference sessions?
- What
- Who
- Scott Stark stated that Red Hat will increase their level of engagement.
- To follow
- GitHub issues for data project
- Data-dev list
- Ed to look to Scott Stark to poll for status regarding these
- Next steps to get “Make Full / Web profile play nice with MicroProfile maven dependencies” / “Normalize Web Profile Dependencies” PR https://github.com/jakartaee/jakartaee-api/pull/139
- Maintenance lead role jea-151: define a way forward
- Ed and Jan to meet 1:1 to define the job to be done.
- CDI and CDI EE
- Breaking up spec/TCK to remove circular dependencies · Issue #687 · jakartaee/cdi (github.com)
- There will be two ballots for this.
- Scott will be putting out a new ballot for CDI EE
- This is either a new spec or a restructuring review.
- Scott will continue to work with Ivar on this.
- Make steps to move CDI some integration concerns from CDI itself to the specs that own artefacts? Platform directed (as it’s a cross-spec thing)?
- Take this as an opportunity to do the right thing for each possible instance of integration challenges. For example Jakarta Servlet and CDI injectability of HttpServletRequest. There is some notion of this being a “built in bean” as defined in CDI.
- Arjan articulated some history
- Before: we were not sure if
- “All the other specs should know about CDI”
- “CDI should know about all the other specs”
- Now: we are sure
- Any steps for a CDI lite API?
- See above. This is addressed as CDI EE
- Maintenance
- JakartaOne Livestream 2023 is taking place Dec 5th this year and CFP will be closing next week. Please submit your talk as soon as you can direct CFP link.
