-
Notifications
You must be signed in to change notification settings - Fork 69
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
f87737b
commit e762241
Showing
2 changed files
with
128 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters