Skip to content

Commit

Permalink
Merge remote-tracking branch 'upstream/gh-pages' into gh-pages
Browse files Browse the repository at this point in the history
  • Loading branch information
ivargrimstad committed Feb 18, 2024
2 parents 1053178 + feda784 commit 096dcba
Show file tree
Hide file tree
Showing 4 changed files with 228 additions and 42 deletions.
94 changes: 52 additions & 42 deletions jakartaee11/JakartaEE11ReleasePlan.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,23 +10,24 @@
| *Platform* | | | Plan Review | | | | |
| *All* | | | | TCK pass w/Security Manager Disabled | | | |
| *All* | | | | M1 release | | | |
| *All* | | | | | Wave 1, 2, 3, 4 specs release review by 2024-01-30 | | |
| *All* | | | | | Wave 1, 2, 3, 4 specs release review initiated by 2024-02-29 | | |
| *All* | | | | | M2 release | | |
| *All* | | | | | Wave 5 specs release review by 2024-02-29 | | |
| *All* | | | | | Wave 5 specs release review initiated by 2024-03-29 | | |
| *All* | | | | | M3 release | | |
| *All* | | | | | Wave 6, 7 specs release review by 2024-03-29 | | |
| *All* | | | | | M4 release | | |
| *All* | | | | | TCK pass on Java SE 21 | | |
| *Components* | | | | | Individual Component Spec Ballots | | |
| *Platform* | | | | | Platform TCK pass on Java SE 21 | | |
| *Components* | | | | | | Complete implementations | |
| *Components* | | | | | Each Wave 1 - 5 component spec has an impl that passes its TCK on Java SE 17 and an impl that passes its TCK on Java SE 21. These need not be the same impl. | | |
| *Components* | | | | | | Each Wave 6, 7 component spec has an impl that passes its TCK on Java SE 17 and an impl that passes its TCK on Java SE 21. These need not be the same impl. | |
| *All* | | | | | | Wave 6, 7 specs release review initiated by 2024-04-27 | |
| *All* | | | | | | M4 release | |
| *Components* | | | | | | Individual component spec ballots completed | |
| *Platform* | | | | | | Platform TCK ready to run on Java SE 21 and Java SE 17 | |
| *Components* | | | | | | Further refine implementations | |
| *Platform* | | | | | | | Platform ballot |
| *Platform* | | | | | | | Web Platform ballot |
| *Platform* | | | | | | | Core Platform ballot |
| *Platform* | | | | | | | **Release** |

For all milestone releases after M1:
* specs that are slated to have release review before that milestone will include their final versions in the milestone.
* specs that are slated to have release review initiated before that milestone will include their final versions in the milestone.
* all other specs will include the latest version they have on hand. (Ed and Arjan commit to do the release work for this case, if necessary.)

## Scope ([issue]())
Expand All @@ -37,31 +38,38 @@ Some of these component Specifications are introducing breaking changes to their
Many other component Specifications are introducing updates which are binary compatible and, thus, will only require a Minor version update.
Regardless of the scope of changes, all artifacts for the component and Platform Specifications will be affected -- Specifications, APIs, TCKs, and Compatible Implementations.

## Java SE 21 ([issue]())
Java SE 21 will become the minimum runtime supported by Jakarta EE compatible implementations.
## Java SE ([issue]())
Java SE 17 will become the minimum runtime supported by compatible implementations of Jakarta EE.

## Jakarta Data
Jakarta EE 11 plans to include Jakarta Data in its platform specification. For more on Jakarta Data see [Jakatra Data](https://jakarta.ee/specifications/data/).
Jakarta EE 11 plans to include Jakarta Data in its platform specification. For more on Jakarta Data see [Jakarta Data](https://jakarta.ee/specifications/data/).

## CDI
Continue to make CDI the single component model used across all of EE by removing Managed Beans from Annotations and all callsites that use Managed Beans.

With the help of the platform project, the CDI project will do the work to move all aspects of CDI that deal with integrating CDI with other specifications out of the CDI spec and into the platform spec or appropriate profile spec. The remaining content will still be called CDI. For more information see the [CDI issue tracker](https://github.com/jakartaee/cdi/issues/687#issuecomment-1667009015).

### API Source and Target Level
If a component Specification is planning a Major or Minor version update for Jakarta EE 11, then the recommendation would be to recompile and distribute the specification’s APIs at lowest required of Java SE 17 and Java SE 21.
### API Source Code `--release` Level

**Note:** A component specification may be required to recompile to a higher Java SE level than it actually use depending on the specifications it depends on.
For the Jakarta EE Platform (Platform, Web and Core), the Java compiler `--release` option is 17. For the component specs, the Jakarta EE Platform requires the Java compiler `--release` option is **at most** 17, but component specifications can decide on a lower level.

### TCK Source Level
The TCK for specifications updated in EE 11 will be compiled at the Java SE 21 level.

- Component spec TCKs and platform TCK must compile at Java 17 or less.
- 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.

#### Signature Tests
In Jakarta EE 9.1, the framework for performing API Signature tests was updated to make it easier to test Signatures across multiple Java levels.
The framework and/or API tests may need to be tweaked as we continue to learn and experiment with future levels of Java.

### Compatible Implementation (CI) Source Level
How a Compatible Implementation supports the Java SE 21 runtime (or above) will be left as a vendor-defined solution.

The long-standing policy of considering specification API binaries, in Maven Central or anywhere else, as a non-normative convenience remains unchanged. The platform project is silent on this matter. However, because the platform project does mandate a specific JDK requirement for compatible implementations passing the component or platform TCK, if a component specification does publish an API binary, that binary is practically constrained to follow that mandate." See [TCK Source Level](#tck-source-level)

## JPMS Module Info classes ([issue](https://github.com/eclipse-ee4j/jakartaee-platform/issues/329))
Suggestions on support for JPMS modules were introduced in the Jakarta EE 9 Platform Specification.
Expand Down Expand Up @@ -113,7 +121,7 @@ List of specifications in Jakarta EE 11 Platform, Jakarta EE 11 Web Profile, and
- Jakarta Debugging Support for Other Languages 2.0
- Jakarta Dependency Injection 2.0.1
- Jakarta Enterprise Beans 4.0.1
- Jakarta Expression Language 4.0
- Jakarta Expression Language 6.0
- Jakarta Faces 4.1*
- Jakarta Interceptors 2.2*
- Jakarta JSON Binding 3.0
Expand All @@ -136,6 +144,7 @@ List of specifications in Jakarta EE 11 Platform, Jakarta EE 11 Web Profile, and

### Proposed Updates to Platform

- Jakarta CDI
- Jakarta Data 1.0
- Jakarta Activation
- Jakarta Annotations
Expand All @@ -157,6 +166,7 @@ List of specifications in Jakarta EE 11 Platform, Jakarta EE 11 Web Profile, and

### Proposed Updates to Web Profile

- Jakarta CDI
- Jakarta Annotations
- Jakarta Validation
- Jakarta Concurrency
Expand Down Expand Up @@ -190,61 +200,61 @@ As stated earlier, all component Specifications which plan a Major or Minor rele

### Waves

We are proposing to deliver Jakarta EE 11 in a set of waves similar to those delivered in the previous Jakarta EE releases. These waves are somewhat related to the dependency tree of specifications. We aim to deliver specifications with a low number of dependencies first followed by other specifications.
We are proposing to deliver Jakarta EE 11 in a set of waves similar to those delivered in the previous Jakarta EE releases. These waves are somewhat related to the dependency tree of specifications. We aim to deliver specifications with a low number of dependencies first followed by other specifications. (updated specifications marked with asterisks)

#### Wave 1

- Jakarta Annotations
- Jakarta Annotations*
- Jakarta JSON Processing* (service release)

#### Wave 2

- Jakarta Expression Language
- Jakarta Interceptors
- Jakarta Lang Model (may be released with Jakarta CDI [Core] in wave 3)
- Jakarta Expression Language*
- Jakarta Interceptors*
- Jakarta Lang Model* (may be released with Jakarta CDI [Core] in wave 3)

#### Wave 3

- Jakarta Activation
- Jakarta Contexts and Dependency Injection
- Jakarta Activation* (service release)
- Jakarta Contexts and Dependency Injection*

#### Wave 4

- Jakarta JSON Binding
- Jakarta Mail
- Jakarta Mail* (service release)
- Jakarta SOAP with Attachments
- Jakarta XML Binding

#### Wave 5

- Jakarta Authorization
- Jakarta Authorization*
- Jakarta Batch
- Jakarta Persistence
- Jakarta RESTful Web Services
- Jakarta Server Pages
- Jakarta Servlet
- Jakarta Validation
- Jakarta WebSocket
- Jakarta Persistence*
- Jakarta RESTful Web Services*
- Jakarta Server Pages*
- Jakarta Servlet*
- Jakarta Validation*
- Jakarta WebSocket*
- Jakarta XML Web Services

#### Wave 6

- Jakarta Authentication
- Jakarta Concurrency
- Jakarta Faces
- Jakarta Authentication*
- Jakarta Concurrency*
- Jakarta Faces*
- Jakarta Messaging
- Jakarta Standard Tag Library
- Jakarta Platform Core Profile

#### Wave 7

- Jakarta Security
- Jakarta Data
- Jakarta Security*
- Jakarta Data*

#### Wave 8

- Jakarta Platform (including appropriate content formerly in CDI EE)
- Jakarta Platform Web Profile (including appropriate content formerly in CDI EE)
- Jakarta Platform Core Profile
- Jakarta Platform* (including appropriate content formerly in CDI EE)
- Jakarta Web Profile* (including appropriate content formerly in CDI EE)
- Jakarta Core Profile*

### Platform and Web Profile Release Candidate

Expand Down
46 changes: 46 additions & 0 deletions minutes/2024/2024-01-16.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Jakarta EE Platform Call

Date: 2024-01-16

Present:

* James Perkins (Red Hat)
* Jared Anderson (IBM)
* Emily Jiang (IBM)
* Jim Krueger (IBM)
* Nathan Rauh (IBM)
* Tom Watson (IBM)
* Scott Marlow (Red Hat)
* Ed Burns (MSFT)
* Nathan Erwin (Individual)
* Ivar Grimstad (Eclipse Foundation)
* Brian Stansberry (Red Hat)
* Cesar Hernandez (Tomitribe)
* Arjan Tijms (OmniFish)
* Kenji Kazumura (Fujitsu)
* Jan Westerkamp (iJUG)
* Petr Aubrecht (Payara)

## Agenda and Minutes

### Mandatory 2FA on GitHub
* Enable it on your account by April 30 to avoid disruptions
* Check [email from Mikael Barbero](https://www.eclipse.org/lists/eclipse.org-committers/msg01409.html)

### JEA-277-mitigate-gh-platform-820
* Review emails from this morning.
* Mark Thomas
* ACTION: Ed: Reply: Need to specify that the minimum level is 17. See the PR linked in JEA-284.
* Steve Millidge
* ACTION: Ed: Acknowledge his position, but no action required.
* Lukas Jungmann
* ACTION: Ivar: has already replied.
* Review release plan changes in [JEA-284](https://dev.azure.com/jakarta-ee-azdo/jakarta-ee-azdo/_workitems/edit/284).

### 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 .
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)
3 changes: 3 additions & 0 deletions minutes/minutes.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,9 @@
* [2019](#2019)

## [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 096dcba

Please sign in to comment.