I've updated dependencies of Jetty to version 12.0.16 (newest stable) and fixed compilation issues.

Please note that due to change from javax.servlet to jakarta.servlet package there is a lot of changes (including changes in class names of parameters passed to public methods). Due to that this change may be problematic to include it in 8.5.0 as it could be a possible API break.

@wojtek Please review my changes in jetty-12 branch. We will merge them either to 8.5.0 (if we decide that those are not breaking changes) or to next version (if changes would be too large).

I was aware that it would entail package change but luckily it would be only this time.

I checked the branch and it looks ok, it seems to be running just fine. Considering that we are not changing our API I think it should be fine. Considering - if someone created something for previous 8.4.0 version (module, rest (groovy) handler, etc) - will it break if someone update to 8.5? AFAIR we had an abstraction layer (because we had two underlying http servers) so for anyone this change should be transparent - correct? (if yes, then it could be merged to master and also tigase-server [distribution] should be updated with dependencies)

AFAIR we had an abstraction layer

@wojtek, we had and we hadn't. There was an abstraction layer for Jetty as we exposed only HttpServlet API (and related).

However, in previous version of Jetty those were from javax.servlet package and now are from jakarta.servlet package. Most APIs are the same for both packets but there were some small differences.

Due to that I've rebased all our code to use only (and expose) jakarta.servlet API. If someone had "custom" code with imports from javax.servlet this code would fail after my changes.

In that case let's push it to 9.0.0.

Do we have any way/deprecation to signal this change?

Well, it may be hard as we cannot annotate not ours classes/interfaces. I think we could only warn about it...

There will be version bump so API changes are expected. Let's leave it as is.