So we should do the same as for GlassFish and keep with WildFly 39 for JakartaEE10 testing. The JakartaEE11 profile does not need to pull the WildFly preview server.
I think it is not worth the effort to test JakartaEE10 with recent WildFly and therefore pull the JakartaEE10 feature pack for a few WildFly versions before it is removed also.
From the announcement mail:
I've talked over the last year or so about providing an EE 10 variant of standard WildFly once we move standard WildFly on to EE 11.
That day is approaching rapidly so I need to get moving on this. So:
Issue: https://www.github.com/wildfly/wildfly-proposals/issues/818
Analysis: https://www.github.com/wildfly/wildfly-proposals/pull/819
Linked from there: https://redhat.atlassian.net/browse/WFLY-21698
We're closing in rapidly on WildFly Preview being EE 11 compatible and it seems highly likely that can be achieved by the planned April 23 WF 40 release.
Once WFP is compatible it's a matter of maybe a day's work to shift standard WildFly to providing EE 11 instead of EE 10. So that could be done for WF 40 as well. But, unlike WFP, standard WF hasn't been providing EE 11 APIs for a number of releases, so if we shift std WF to EE 11 APIs we'd want to do that for 40 Beta, which is scheduled for release next week.
When we move std WF to EE 11, we also want to provide this EE 10 feature pack, and continue to provide it for a couple quarters, to give our users a chance to adapt to EE 11 while still getting bug fixes and other new features. It would be good to provide this with 40 Beta as well.
The Redhat issue talks also about removing the SecurityManager in the future. If this happens, we could do a final 2.0 release and then switch to a 2.1 version without SecurityManager.
So we should do the same as for GlassFish and keep with WildFly 39 for JakartaEE10 testing. The JakartaEE11 profile does not need to pull the WildFly preview server.
I think it is not worth the effort to test JakartaEE10 with recent WildFly and therefore pull the JakartaEE10 feature pack for a few WildFly versions before it is removed also.
From the announcement mail:
The Redhat issue talks also about removing the SecurityManager in the future. If this happens, we could do a final 2.0 release and then switch to a 2.1 version without SecurityManager.