Test harness depends on Jetty 6.1.26 from 2010, the last release of the org.mortbay.jetty coordinate

Spun out of the estate-wide Jetty review in [apache/maven#12768](https://github.com/apache/maven/issues/12768), triggered by the Jetty 9/10/11 end-of-life announcement in [jetty/jetty.project#13918](https://github.com/jetty/jetty.project/issues/13918). This repository is not covered by that announcement — it is on something considerably older.

## Where we stand

`pom.xml` has a test-scope dependency on `org.mortbay.jetty:jetty:6.1.26`.

`org.mortbay.jetty` is the pre-Eclipse groupId, and 6.1.26 is the last release ever published under it: 10 November 2010. There is no newer version of this coordinate and there never will be, so unlike the Jetty 9 cases elsewhere in the estate there is not even an end-of-line bump available.

The only consumer is `ProjectInfoReportUtilsTest` — one test method, `testGetInputStreamURL`, which stands up a server and checks that `ProjectInfoReportUtils.getContent` reads a URL correctly. It uses `SelectChannelConnector` for plain HTTP, `SslSocketConnector` for HTTPS, and `HashUserRealm` with `Constraint`/`ConstraintMapping` for basic auth, across a few character encodings.

Test scope, so nothing ships and nothing breaks. This is hygiene, not exposure.

## Options

**1. Move to the end of the Jetty 9.4 line** (`9.4.58.v20250814`). Still Java 8, so it works with the current `javaVersion` 8 baseline and the inherited CI matrix that includes JDK 8. It is a rewrite of the fixture rather than a version bump — the whole connector and security API changed between Jetty 6 and 9 — and it lands us on a line that is itself end-of-life. Fifteen years newer, but still a dead end.

**2. Drop Jetty and use the JDK.** What this test needs is a local HTTP server, a local HTTPS server, and basic auth. `com.sun.net.httpserver.HttpServer`, `HttpsServer` and `BasicAuthenticator` have been in the JDK since 6 and cover all three. That removes a dependency instead of moving it, keeps the Java 8 baseline, and does not have to be revisited when the next Jetty line goes end of life.

For a 253-line test class with a single server-based method, option 2 looks like less work than option 1 and a better end state. Worth a look before anyone invests in the Jetty 9 port.

Jetty 12 is not on the table here regardless: it needs Java 17, and JDK 8 is still in this repository's CI matrix.

*This issue was created with AI assistance.*

Start with pom.xml and ProjectInfoReportUtilsTest, especially testGetInputStreamURL, and run that test to understand its HTTP, HTTPS, basic-auth, and encoding checks. Replace the Jetty-based fixture with the JDK HTTP servers while preserving those checks, then confirm the test passes on the Java 8 baseline and the old test dependency is gone.

Written by the indexing model from the issue text.