Improve EE10 compatibility #350
Conversation
Mainly to be used to switch versions of dependencies etc.
Latest stable, minimal update.
- Add Jakarta EE9 and EE10 compatible Payara versions - Add configuration to run Arquillian integration tests in a managed instance of Payara - Add JUnit category to skip tests that should be ignored on Payara
With CDI 4.0 and Faces 4.0 you need to explicitly enable CDI by providing at least an empty beans.xml file. Adding this to the test deployment makes the test run again.
With CDI 4.0 the default for bean discovery switched to annotated beans only. It is necessary to switch back to the old default of scanning -all- classes. This means that any application using this library via CDI or Jakarta Faces will have to enable this, too!
|
Hey @poikilotherm - Thanks for the PR & update! Thanks for the I did a quick review, and it looks like you've introduced a new EE10 profile. Can you tell me how this is intended to be used? I assume it needs to be specified along side (together with) one of the other managed profiles? Additionally, it looks like some tests are now failing on Wildfly, but I'm not sure why anything would be different. All you did was bump a version for that profile, right? Is it possible there is now a mismatch? It looks like there are some strange classpath issues causing test deployment failures: |
|
Hey @lincolnthree , basically the first PR was never all set and done with EE10 as it was still using Wildfly 26 and EE9.1. Most of the patches were left stashed in my local branch. The new profile was because of trying to not create another feature branch for EE10 which would need extra maintenance. I had hoped to create a profile might be enough to get us going and maybe release Jars like Primefaces does it for EE8 and Jakarta-based. Now that the branch is a reality we might just skip that. The tests fail because of the CDI and Faces changes in EE10, see TODOs above. |
|
Gotcha! That makes sense. Thanks for the extra info :) I appreciate your efforts on this! Let me know if there's anything I can do to support you with the CI or GitHub infrastructure. |
Not just EE10 but also EE9.1 already needs the Alpha releases of Payara and Wildfly Arquillian plugins.
- Adding runs for Jakarta EE 9.1 and EE 10 - With both Wildfly and Payara - Depending on the Jakarta EE version the appropriate appserver version is set
To easier keep track of failing modules, introducing a property makes it easier to switch them on and off for further testing. Plus identifying affected modules is much easier this way.
Testing with LTS (17) and latest (19)
Use shorter names but add nice matrix parameter names
Usually, application server do not support running on latest Java but LTS only. Instead of waisting CI CPU cycles with unknown side effects, skip those.
- Always add the beans.xml as JSF 4.0 will require it to find things from our lib (no CDI activated from JSF anymore) - Update faces-config.xml and web.xml to the JSF3.0 minimum version
- Both tests seem to trigger some kind of bug in Payara. - The workaround for SchemalessCDNRuleIT is only necessary for Payara 5 - works as designed on Payara 6! See also: payara/Payara#5842
Adding Payara to list of appservers to ignore as formerly done with Wildfly and Glassfish. Left comment where appropriate.
- Cleanup POM - Make integration tests run on both EE 10 and EE 9 for both Payara and Wildfly
poikilotherm
force-pushed
the
improve-ee10
branch
from
bfbdd32 to
0606c26
Compare
- Allow to exclude tests from running by Payara version - Make use of for SchemalessCDNRuleIT which works fine for P6
- Do not use an older version of Spring WebMVC than given in POM - Do not run for Payara 5 - is not Spring 6 compatible for unknown reasons...
|
@lincolnthree I managed to get all tests running on both Payara + Wildfly plus Jakarta EE 9.1 and 10. Please note that @larsgrefer did change some modules to ignore outcomes of ITs in As the codebase now should work with both EE9 and EE10 - should we think about releasing JARs to central from one branch for both "versions"? (They only differ in dependencies.) The idea is obviously to add a classifier for one of both flavors. Note this will not show up on UIs like mvnrepository.com, that would require different version tags. On the other hand: now that EE10 is here to stay and some EE9 appservers are becoming enterprise only - maybe a classifier for EE9.1 is fine? |
|
Alright forget that about the classifier - not going to work easily with the shade plugin. Will add some more cleanup with updated plugin dependencies etc. |
- Make plugin versions properties - Add them all to <pluginsManagement> to control the version in all submodules - Move config to this section, too, where appropriate
Make it more inline with the other for Payara.
…gent> for all modules
As we need to change to the branch model to release different versions of the library (classifiers are no use because the shade plugin is hard to configure with it), let's make the Jakarta EE 10 variant the default but still enable building with Jakarta EE 9.1 for tests.
Moving to a new major release of Jakarta is a breaking change requiring a major release number increase.
|
Alright @lincolnthree:
Question for you: should we setup a deployment pipeline for snapshots and releases? I've done this before for https://github.com/gdcc/xoai and https://github.com/gdcc/sword2-server, so can inherit from there. Another question for you: what kind of docs do you want me to include? Should I update the README, add build status, EE version with badges, etc? Should this even be a part of this PR or for a next round? |
|
Hey @poikilotherm, thank you for the continued work! I think the first thing we should do is publish another Alpha build in central and get some real-world results (I believe there is already one published if you check 6.00.Alpha1, but I don't believe it includes your changes for Payara). A deployment pipeline for releases would be awesome, but unfortunately I don't have a lot of free time to set that up at the moment. I wish I had time to look at why the ITs are failing on certain containers as well, but alas... Anyway, I believe snapshots should be auto-published already via the existing GitHub workflows? Let's do the work of getting a consumable JAR/distribution build published first, then we can get the docs updated in a subsequent PR. |
|
I'm not sure how long snapshots stay in this repo. It looks like they have rolled off already: |
|
@larsgrefer Do you happen to know how long SNAPSHOT builds stay published on sonatype? Or am I looking at the wrong repo? |
Closes #345
Discoveries so far:
beans.xml. Discovery mode seems to be necessary to be set toall, which is different than the defaultannotated! See spec This means that any app using this lib via CDI or Jakarta Faces will need to enable this discovery mode, too! (This should be documented and maybe fixed at a later point in time.)TODOs: