Add Jakarta EE 10 compatibility #349
Conversation
To more easily change and reuse the Jakarta and Spring versions to be used, add properties for these. Change showcase POMs to use these versions and remove any hardcoded versions, instead rely on BOMs.
Instead of relying on Java 17+, this should be buildable with JDK 11, too. Let's test in CI if this works.
We need to use JDK 17 but built for 11. Needs better way to do this. This reverts commit 731d543.
- Adding compiler config to build for JDK 11 but using JDK 17 to be Spring 6 compatible - Adding enforcer check in parent to make sure anybody trying to build with JDK 11 (minimum for Jakarta EE 10) keeps away from that.
Mostly adding the Injection API because JSF beans go away with Jakarta EE 10.
JSF @ManagedBeans have been deprecated since JSF 2.0. With Jakarta EE 10, these go away. Replacing them with normal CDI injection.
Certain servlet methods have been deprecated long time ago. With Jakarta EE 10, these go away. Replacing them where possible.
The CDI methods to fire events in use within this library have been deprecated since CDI 1.1. With Jakarta EE 10, these go away. Reducing them with the official ways outlined within CDI 3.0 spec to be compatible with Jakarta EE 9 and EE 10.
…space The XSD location has changed with Jakarta EE 9, fixing that.
With Jakarta Faces 4.0 contained in Jakarta EE 10, the long deprecated JSP support has been dropped. To make this library usable with both EE 9 and EE 10, the JSP tags should simple go away. People should use JSF components instead.
|
Hey @larsgrefer @lincolnthree maybe you can take a first look at this? @lincolnthree can you tick off the workflow run? Thanks! |
|
Hey guys. First, my apologies for keeping you all waiting for so long after putting in so much work on this. This summer has been incredibly challenging for personal reasons, so I just want to say thank you for your patience and I'm sorry again. I'm back in the saddle for a bit and will get the workflow (and hopefully discussion) started back up again on this. |
|
And yes, @poikilotherm if you wanted to add a test-suite ad GitHub automation for Payara that would be excellent! The more containers the merrier!! |
|
@poikilotherm One question. Is Jakarta EE 10 backwards compatible with 9? Should this have its own branch? Also currently trying to figure out why actions are not available on this PR. Working on it... |
|
Don't worry when you see this @poikilotherm I'm closing this temporarily to try opening a new PR and see if that gets actions working. |
|
Ok simply closing and re-opening did the trick. Strange. |
|
@poikilotherm @larsgrefer Given that this removes support for JSP, which is still compatible with EE 9, I'm inclined to base this on a new |
|
I'm approaching in the midst of my upgrade to EE10 and (Wildfly 27) and I'm wondering where we stand on this? |
|
Hey @codylerum . As far as I know, this needs a new branch, and some snapshots. Would that help in your testing? I can make it happen tomorrow. |
lincolnthree
changed the base branch from
develop-jakartaee-9
to
develop-jakartaee-10
|
@poikilotherm @codylerum 6.0.0.Alpha1 (which should support EE10 via this PR) should be in maven central soon. Just did the release. |
|
@lincolnthree Thanks I'm hoping to take it for a spin in the next week or so |
Closes #345
Closes #346
This isn't ready yet, as I want to change the Github Action to build with both Jakarta EE 9 and EE 10, so down the road we can make sure it builds and runs with both.
This also means adding Wildfly 27 into the mix, which is their first EE 10 based release. Currently in Alpha, but nearing the finish line just as Payara.
If you folks feel we should add a Payara 6 testing flavor, too, please speak out.
If you want me to split up the PR in multiple smaller ones, please let me know.