Control: tags -1 - moreinfo
On 24/04/2025 17:06, Paul Gevers wrote:
I believe it is too late to replace jetty9 in trixie as it has quite
some reverse dependencies. We prefer not to have multiple versions of
the same thing in a stable release. Why would we want to have jetty12 in
trixie?
I agree it's too late for a full transition to Jetty 12, but several
packages only use jetty9 to run unit tests or for minor features. The
idea is to leave them as-is for Trixie, remove the jetty9 server package
but keep the libjetty9-java library.
There are 11 reverse dependencies using Jetty at runtime:
- eclipse-equinox and eclipse-platform: the lack of jetty12 blocks the
upgrades, the packages lag 1.5 year behind upstream releases.
- jalview: desktop application exposing a local SOAP/REST endpoint with
Jetty, can remain with Jetty 9.
- jgit: Jetty is used for unit tests only
- logback: has logging support to Jetty 9 but is not used in practice,
no need to change for Trixie
- lucene9: Jetty is used for unit tests only (libjetty9-java should be
removed from the package dependencies)
- libmaven-site-plugin-java: Jetty can be used to preview a Java project
web site locally, but the plugin is actually unused in Debian, can be
ignored for now.
- ring-clojure: the Jetty adapter is unused (popcon 1)
- trapperkeeper-webserver-jetty9-clojure: specific to Jetty 9, Puppet
hasn't upgraded Jetty yet and will stick to Jetty 9 in Trixie.
- zookeeper: upstream is still on Jetty 9, no pressure to upgrade
- openrefine: likely to be removed in May due to other issues
Allowing jetty12 in Trixie would enable us to have up to date Eclipse
packages and a recent and supported version of the Jetty server, on par
with the Tomcat package. The risk of regression is limited because the
full transition will not happen before Forky.
Emmanuel Bourg
