GH-4603 Upgrade to JavaEE/JakartaEE 8

[erikgb]

GitHub issue resolved: #4603 #4252

Briefly describe the changes proposed in this PR:

Upgrades JavaEE/JakartaEE dependencies to version 8 using the Jakarta dependencies managed by the Jakarta EE 8 BOM. Jetty also needs to be upgraded to version 10 to be compatible with JavaEE/JakartaEE, and is also included in this PR.

---

PR Author Checklist (see the contributor guidelines for more details):

• my pull request is self-contained
• I've added tests for the changes I made
• I've applied code formatting (you can use mvn process-resources to format from the command line)
• I've squashed my commits where necessary
• every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change

[abrokenjester]

Still on holiday, but just quickly dropping by to say this looks ace to me!

[hmottestad]

I'm not sure what the implications of the jetty issue is. Does it mean that we are shipping with one version in one part of our code and another version somewhere else?

Edit: I'm also wondering if our users could run into any conflicts in their own code.

[hmottestad]

I'm still not sure what this means for us.

[erikgb]

It means what it says in the comment. 😉 Some of the Solr dependencies used for testing are hard-locked to Jetty 9. I hope we can fix this by upgrading Solr before rdf4j 5 is released. Or even better: find a way to avoid being dictated by legacy transitive dependencies.

[hmottestad]

Also not sure what this means for us.

[erikgb]

We must choose to have jakarta.* or javax.* dependencies. Never both. As there is a BOM for Jakarta dependencies, I would prefer to use that one.

[erikgb]

I'm not sure what the implications of the jetty issue is. Does it mean that we are shipping with one version in one part of our code and another version somewhere else?

If this is merged and released, we would use Jetty 9 in the Solr compliance module and Jetty 10 in the other modules. I am assuming a very little percentage of our users are actually using the compliance modules, as it appears to be a mostly internal module containing tests. But please correct me if I am wrong.

[hmottestad]

If we need to use Jetty 9 in the Solr compliance module, wouldn't our users run into issues if they rely on the Solr module (not compliance) together with another module? Would they end up with a having to exclude Jetty 10 to get Solr working?

[erikgb]

If we need to use Jetty 9 in the Solr compliance module, wouldn't our users run into issues if they rely on the Solr module (not compliance) together with another module? Would they end up with a having to exclude Jetty 10 to get Solr working?

I think you are right that this might be an issue. The embedded Solr pulls in Jetty dependencies. I thought it was just test dependencies, but sadly not. Any suggestions for a workaround? Doing everything in one PR does not seem right to me.

[hmottestad]

Probably need to update Solr, unfortunately. Which entails updating Lucene and probably Elasticsearch.

I think it's worth double checking how jetty impacts our use of Solr. I assume that our Solr code is just client stuff and that the server stuff is only used for the embedded Solr during testing. Maybe the client code doesn't depend so heavily on Jetty?

Updating the elasticsearch stuff is a true pain due to their licensing, multiple breaking changes and them changing up their client every few months.