Lift 4: update dependencies

[dpp]

https://groups.google.com/g/liftweb/c/sG2HWm4I3g0/m/lYvrejBkCAAJ?utm_medium=email&utm_source=footer

Vitalli: Another thing I see here is the end of community support for Jetty 9.x. All the newer versions of Jetty use Servlet versions higher than 3.1. It would be nice to bring support for the newer Jetty versions.

Andreas: Yea, and change all references from javax => jakarta

[fanf]

I think this is not a lift 4 only thing but should even be done in a lift 3.n+1 one.

This is becoming a blocking issue for maintenance of old lift applications as soon as they are integrated with Java framework. The last example in date is spring / spring security. We use it for authentication, and spring is dropping the 5.x branch in August 2024, which means that from that point, we won't even have security update.

For that reason, the port to servlet 4+ should be made in a no other breaking change. The actual change was already done in the Olon fork of lift : Carlos Saltos wrote on the mailing list https://groups.google.com/g/liftweb/c/oApVVmAUop0/m/whz2hX98BAAJ :

Here a reference commit for an update to Jetty 11 and Servlet API 5 with a Lift fork -> https://github.com/talenteca/olon-web-framework/commit/31cc0dcf91eb7fa4693c2d3166d7a7c39b31bd79

The main changes are at JettyTestServer and HTTPRequestServlet with the new usage of multiparts upload included at Jakarta new Servlets 5.

These changes are still under testing but I hope once stable soon these changes can be included at official Lift new versions.

The new Jakarta Servlets 5 are not working for filters so an Apache commons fileupload2 for Jakarta is using now very similar to the original javax old API usage, more info at -> https://github.com/talenteca/olon-web-framework/commit/4e7a7de8059cf8250024957f7f42c7f619a69dfe

on lift versionining scheme

Actually, I think lift should adopt the following versionining scheme to let more people contribute to their use case and make Olon commit easier to integrate :

• 3.x branch is kept for possible security issues on currently supported scala branches. It targets lift applications in maintenance / phase out mode that are expected to be upgraded ever, but might need a security fix. It's expected to have almost no commits, but who knows

• 4.x branch is used for old lift application that are still actively maintained. Changes try to keep existing api with minimal changes and the immediate focus is on updating libraries and getting a better compatibility to Scala 2.13 (typically on scala XML). If stars align scala 3 compat might be imagined but it's not the primary goal, and it shouldn't be done at the price of Scala 2.13 compat. It can also be used in the longer term to bridge the path with lift 5. Some of the changes from Olon could be directly used for that branch.

• 5.x branch is the fresh start that focus on scala 3, cleaning up things, and all the nice ideas that are tagged lift4 for now. Since there is a 4.x branch for maintenance, that 5.x branch could be quite free to move fast and break things, which I fear would be a concern in the current existing versionining scheme.