It’s actually the current situation that doesn’t obey our strategy IMO
This will allow to make XWiki work on Jetty 10.x OOB without having to edit jetty-web.xml to remove the lines there:
<!-- Tell jetty that javax.mail should be something that is invisible to the user, but if it's provided inside the
webapp use that instead (this is the case for XWiki). This is needed for work around issue
https://github.com/appropriate/docker-jetty/issues/108. Note that we don't have this problem in the XWiki
Standalone packaging since we create a custom distribution of Jetty and we don't include the Jetty "mail"
module. However we have the problem in our functional Docker-based tests where we use the official Jetty
image. -->
<!-- Note: This works for Jetty 9.4.x. If you're deploying on Jetty 10+ you must remove the 2 calls to
getSystemClasspathPattern and getServerClasspathPattern, as otherwise XWiki will fail to deploy. In Jetty 10+
it's no longer necessary to have this hack. Right now we provide a jetty10-web.xml file in the docker test
maven module to make it work on Jetty 10+. Once all the Jetty version we use are >= 10.0 then we'll be able
to remove these calls below and the jetty10-web.xml file. -->
<Call name="getSystemClasspathPattern">
<Call name="add">
<Arg>-javax.mail.</Arg>
</Call>
</Call>
<Call name="getServerClasspathPattern">
<Call name="add">
<Arg>javax.mail.</Arg>
</Call>
</Call>
I don’t fully agree that Jetty 10 is the current LTS given the special nature of the Jetty 10/11 couple. Those are more treated on Jetty side as both being the current version (they have the same lifecycle and both get new stuff) and are more related to trying to propose a way to be nice in this time of javax → jakarta mess.
However, if others wants that I’m not against saying that for 14.x we decided to prioritize Jetty 10 in terms of working OOB because it’s too much of a pain to have both working OOB (as a bonus the Jetty 10 version of the setup is much cleaner from what I understand) and Jetty standard is hardly the most used application server with XWiki. We are supposed to support Jetty 10 anyway, and it’s not like it would make totally impossible to use XWiki with Jetty 9.4.x (we can still document how to do it).
Just to give another input to help others think about this issue: Jetty 10 is not provided yet in any of the Debian/Ubuntu distributions repositories (not that it matter much in the context of XWiki, but it’s an interresting information regarding the status of Jetty 10 in general).
I’m not sure if this is fully correct. The current version is not 10.1 or 10.x but 10.0.7, suggesting that Jetty 10.0 is very stable and a LTS (it has received 7 bugfix versions so far). I’m not saying that Jetty 10.1.x would be stable if it existed (it doesn’t) but that IMO Jetty 10.0.x is considered as a LTS.
Thomas raised some questions about dropping support for Jetty 9. I don’t think it’s hard to continue supporting it, as I think we just need to provide a jetty9-web.xml file that we use in our func tests.
So maybe the best is to continue supporting Jetty 9.x for a while, and to continue to have Jetty 10 be the default config. WDYT?
Thx