Can't upgrade Jetty version about http4k

[FredNordin]

What happens when Jetty 13 is released? 😁

[FredNordin]

What I'll do is to upgrade the dependencies for the server and client to 12 and then see what breaks.That should give us a fair idea of the impact. I would guess most things in the server, like HTTP and SSE handling, would break, as well as the client body handling, because that model has completely changed. That's what I get for contributing the client and SSE code in the past 😆

[daviddenton]

Unfortunately, Jetty 12 is almost a total rewrite of the Jetty 11 APIs and thus will require significant rework of the http4k code as well. Also, the migration docs aren't very informative (happy to be wrong on this if people have pointers!).

We do know about it but would appreciate any help to get the APIs migrated - it's definitely not a priority for us (especially because we personally tend to use Undertow as our server of choice :) )

[FredNordin]

I would suggest to create new client and server modules to support Jetty 12, seeing as the API, as well as class and package names, have changed so significantly. So for example, http4k-server-jetty12 and http4k-client-jetty12.
That would allow users to chose whether they want to use the latest Jetty version or still stay on version 11 (both will be supported by Jetty for years).
That would also make the migration path easier for users that have custom Jetty setups, like servlets and filters, that would also have to be migrated before making the leap to version 12.

I'd be happy to work on the new modules, if @daviddenton and @s4nchez agree with the proposed approach.

[daviddenton]

it's what we did for apache 4-5, so that seems ok - however for that version we actually made the OLD one the versioned one and left new one to be without the number. I'd propose the same thing here, so we'd have:

http4k-server-jetty-11 (v11)
http4k-server-jetty (v12)

[FredNordin]

Seriously though, the naming of the new modules is less of an issue and I would always favour consistency.

[daviddenton]

As long as the APIs are compatible, we've generally upgraded major versions silently (with a Semver bump of course) as it doesn't really affect the vast majority of users. eg. we went from jetty 8 -> 11 with no issues :)

[FredNordin]

I'm tempted to have a go... (famous last words)

[FredNordin]

So the module name of org.eclipse.jetty:jetty-server is still the same in version 12, which mean we won't be able to (AFAIK) have two versions defined in the versions.properties file for refreshVersions plugin. That means, unless we do something hacky, that having two modules targeting different versions of Jetty would be difficult.
Maybe just have to bite the bullet and upgrade Jetty to 12...

[daviddenton]

We might be able to work around that, so having a decent idea about the work involved in an upgrade would be helpful. J21 is out now, so (as soon as Helidon upgrades to it - the preview features flags from v20 are incompatible with v21! 🙄 ) we can actually bump the major version number, which would be a good time to upgrade to Jetty12 as well :)

[FredNordin]

I've started work on the server side. Not too bad so far - just have to code to the Jetty API instead of the servlet API. That probably means that dependency (Servlet) can go from the module.

[FredNordin]

I've not had the time to work on this for a while, but I will continue today.

[daviddenton]

This is due for the next release (5.12.0.0), so am closing