Skip to content

Commit

Permalink
Add minutes for Jan 23 call (#825)
Browse files Browse the repository at this point in the history
  • Loading branch information
ivargrimstad authored Jan 29, 2024
1 parent f87737b commit e762241
Show file tree
Hide file tree
Showing 2 changed files with 128 additions and 0 deletions.
127 changes: 127 additions & 0 deletions minutes/2024/2024-01-23.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
Jakarta EE Platform Call

Date: 2024-01-23

Present:

* Arjan Tijms (OmniFish)
* James Perkins (Red Hat)
* Ivar Grimstad (Eclipse Foundation)
* John Clingan (Red Hat)
* Jared Anderson (IBM)
* Kyle Aure (IBM)
* Emily Jiang (IBM)
* Jim Krueger (IBM)
* Riva Philip (IBM)
* Nathan Rauh (IBM)
* Tom Watson (IBM)
* Adam Yoho (IBM)
* Scott Stark (Red Hat)
* Nathan Erwin (Individual)
* Scott Marlow (Red Hat)
* Brian Stansberry (Red Hat)
* Cesar Hernandez (Tomitribe)
* Dmitry Kornilov (Oracle)
* Petr Aubrecht (Payara)
* Ed Bratt (Oracle)

## Agenda and Minutes

### JEA-277-mitigate-gh-platform-820
* Baseline JDK is now JDK 17 as to Red Hat’s request
* Email from steering committee
* Question -> must process be followed
* Wayne mentioned spec process doesn’t require a vote
* Spec committee will have a vote
* Progress review needed
* Some concerns about virtual threads
* Oracle
* A compatible component impl must pass their component TCK when run under Java 17 or 21.
* To ratify a component specification, there must exist an implementation that passes on Java 17. There must also exist an implementation that passes on 21.
* These need not be the same implementation. There can be one implementation that passes on 17 and a different one that passes on 21.
* A compatible platform impl must pass the platform TCK when run under 17 or 21.
* To ratify a platform specification, there must exist an implementation that passes on 17. There must also exist an implementation that passes on 21.
* These need not be the same implementation. There can be one implementation that passes on 17 and a different one that passes on 21.
* Discussed the above
* Steve Millidge
* Steve brought it up at the steering committee
* Specification committee will discuss it
* GlassFish community
* Revert 8.0 branch to JDK 17
* Anyone against it in this group? -> Nobody against it

### Marlow: Unknown when EE 11 Platform TCK will be ready for Platform/profiles Spec ratification.
* Appclient container support is being worked on now.
* TCK Test vehicles need equivalent.
* Most of the tests need further work for deploying and running on EE 11.
* EE 11 specific tests will be needed
* Enough such that there is enough testing to be determined.
* We also will need EE 11 Platform/profiles to be implemented that can run on .
* Make list of TCKs that still need to start migration
* Servlet done
* Security done
* Faces done (with including the old tests inside the new build)
* Persistence need to be done
* Batch already had standalone
* CDI already had standalone
* Authorization needs to be done
* WebSocket?
* Concurrency?
* EJB?
* Test vehicles
* Mostly Servlet is important
* Jakarta Persistence uses Java SE vehicle
* SE vehicle vs EE vehicle (what’s the exact difference, do we need some definition for that?)
* Map to an Arquillian container
* Appclient based test
* Modification to standard container for Arquillian WildFly
* Protocol adjustment
* Appclient needs two deployment
* Formatted log parsing as output
* Servlet has simplest impl (maps directly) \

* JavaTest
* Quite complex
* No trivial mapping from JavaTest to Junit
*

### Rest 4.0 becomes Rest 3.2
* Deprecation of @Context
* Implement an alternative CDI based solution already?
* Deprecated something needs alternative
* May be difficult to implement
* Resources available for REST?
* REST was not able to make 4.0 deadline because of resource issues
* Hard to say - RestEasy might be CI for REST 3.2
* James working on that (for RestEasy)
* How much time would REST 4.0 still need?
* Realizing that in 3.1 @Context would be removed in “some” future release
* Concern that there was no formal deprecation. Without that formal deprecation there might be problems with implementors
* Effort not terribly much different
* Might even be more (supporting two injection implementations)

### Jakarta Data implementations
* Join forces by Red Hat and glassfish community
* IBM able to chip in?
* Payara?
* Tomitribe?
* Chat with Gavin King
* How much existing code could be used
* Scott will talk with Gavin on January 24
* Static meta model
* Might be merged in
* Can implementation use Jakarta Persistence APIs only?
* Nathan: yes
* No need to have the Eclipse EE4J implementation done within the EclipseLink project. Could be standalone project using JPA/jakarta Persistence APIs, could even bypass Jakarta Persistence entirely and just use JDBC
* Or are Hibernate / EclipseLink specifics needed? -> No

### Validation
* Any progress?
* Yes - Scott working on the update
* Will produce release

### M2 Dates:
* [Jakarta EE 11 Release Plan](https://jakartaee.github.io/platform/jakartaee11/JakartaEE11ReleasePlan)

### CDI
* The EE portion needs to be rehomed (profile on the platform)
1 change: 1 addition & 0 deletions minutes/minutes.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@

## [2024](#2024)

* [2024-01-23](2024/2024-01-23.md)
* [2024-01-16](2024/2024-01-16.md)
* [2024-01-09](2024/2024-01-09.md)

Expand Down

0 comments on commit e762241

Please sign in to comment.