slachiewicz opened a new issue, #1298: URL: https://github.com/apache/maven-site-plugin/issues/1298
Jetty 9, 10 and 11 stopped being published to Maven Central on 1 January 2026 — see [jetty/jetty.project#13918](https://github.com/jetty/jetty.project/issues/13918). Estate-wide context and the shared constraints are in [apache/maven#12768](https://github.com/apache/maven/issues/12768); this issue covers maven-site-plugin only. ## Where we stand `pom.xml` sets `<jettyVersion>9.4.58.v20250814</jettyVersion>` and declares `jetty-server`, `jetty-http`, `jetty-servlet`, `jetty-webapp` and `jetty-util` at **compile scope** (`jetty-client` and `jetty-proxy` are test-scope). `SiteRunMojo` builds a `Server` and a `WebAppContext`, and `DoxiaFilter` re-renders each requested document on the fly, which is what makes `site:run` useful — you edit a page, refresh, and see it. That compile scope is the point of this issue. Of everything in the estate, this is the Jetty that lands on a user's machine. 9.4.58.v20250814 is the last release of the 9.4 line, so there is no version bump available. Nothing breaks — the artifact stays on Central — but a future CVE in it will not be fixed publicly. Two things bound what we can do: - Jetty 12 requires Java 17 (`jetty-server` 12.x is class file major 61); this plugin sets `javaVersion` to 8. - The build matrix still includes JDK 8 (inherited default `[ "21", "25", "8" ]`), so Jetty 12 cannot enter the build in any scope, not even test. ## Mitigating factor `site:run` defaults to `host=localhost`, `port=8080`. It is a developer preview server on the loopback interface, not something deployed. The realistic attack surface is narrow, and that is worth weighing before anyone spends a release cycle here. ## Options **1. Accept it.** Document that `site:run` embeds an EOL Jetty and revisit when the baseline moves. Costs nothing, and the loopback default makes it defensible. It does mean knowingly shipping an HTTP stack that will never be patched again. **2. Raise the baseline to 17 and port to Jetty 12.** `org.eclipse.jetty.ee8:jetty-ee8-webapp` is current at 12.1.12 and keeps `javax.servlet`, so the servlet API need not change — but the handler API underneath did, and the baseline bump needs JDK 8 out of the matrix plus its own discussion about who still runs `site:run` on Java 8. **3. Drop the servlet container.** What `site:run` needs is: serve a directory, and route document requests through the render logic in `DoxiaFilter`. `com.sun.net.httpserver.HttpServer` has been in the JDK since 6 and covers that. `DoxiaFilter` is around 200 lines and its coupling to the servlet API is thin — request path in, response bytes out — so this is a reimplementation of the render-on-request loop rather than a straight swap. In exchange the plugin drops six dependencies, keeps its Java 8 baseline, and the problem never comes back. Option 3 is the only one that removes the problem rather than deferring it, and it is the one I would pursue. Option 1 is a reasonable interim while that is being written. Whichever way this goes, the next generation of the site plugin for Maven 4 should not inherit Jetty 9. *This issue was created with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
