Upgrade to Spring 6 and Spring-Boot 3

[fkleedorfer]

GitHub issues resolved: #5076, #5063,

Briefly describe the changes proposed in this PR:

We don't want to break rdf4j for existing users, so we have to make new artifacts.

Approach:

• Copy spring-components to spring6-components,
• Rename modules: s/spring/spring6/
• update those modules to latest spring/spring-boot versions (major versions 6 and 3, respectively), adapt dependencies, fix whatever needs to be
• Copy tools/server-spring to tools/server-spring6
• update that module to latest spring/spring-boot versions (major versions 6 and 3, respectively), adapt dependencies, fix whatever needs to be

Note: There is substantial code duplication between the two submodules, the changes required for spring6 are minimal. However, extracting common code requires additional work and might lead to bugs, I would be happy to leave things as is, for now.

Multiple Submodules of tools not changed

Some submodules of tools were not duplicated/adapted to spring6 and thus still use spring5:

• rdf4j-http-server
• rdf4j-federation
• rdf4j-runtime-osgi
• rdf4j-workbench

Transitively, they all depend on Spring 5, and I am not sure if they should be duplicated or updated. I am leaning toward duplicating, but it's a lot of duplication, and it would warrant some restructuring work: I'd introduce a tools/spring5 and a tools/spring6 intermediate pom-packaged parent for all the config changes, without changing the original artifact names for backward compatibility - thus, it will be clear how to handle the upcoming Spring 7 release.
I would suggest leaving this aspect (handling other submodules of tools) out of this PR.

Github Actions bumped to Java17

GitHub CI actions have to be changed to use Java 17 instead of Java 11, as spring 6 artifacts come compiled for that version. RDF4J still compiles to 11, so it should not impact clients. Necessary changes have been made (mosly including artifacts that are shipped with JDK versions < 17).

---

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

[fkleedorfer]

@hmottestad Any guidance on how to get the tests to run all the way through?

[fkleedorfer]

... They do not fail, they just time out

[hmottestad]

There is a brittle test in the ShaclSail. Sorry about that. I've been trying to make it robust, but there are just too many edge cases.

The reason why the build(11) is stuck is that you need to have a build that uses Java 11.

We are stuck on 11 until our next major version, but if you just want the tests to pass you can add your own GitHub action that has the same name and just doesn't do anything.

[fkleedorfer]

I understand we are stuck on Java 11 as the target version until the next major version at least, but why is using Java 11 required for building?

[fkleedorfer]

I tried removing version jdk version 11 from all matrix parameter expressions in the github actions, assuming that that's where the required check build(11) comes from - but that does not seem to be the case. Where in the repo is this check configured? Or is this check part of the protected github repo configuration?

When you say, 'adding a github action with that name', do you mean a file .github/workflows/build.yml with this content:

name: build(11)

on: pull_request

?

[hmottestad]

I just managed to merge main into develop, so if you rebase your branch onto develop your build should be a lot more stable.

The requirement for java(11) is configured in the GitHub repo setting somewhere by the webmasters at Eclipse Foundation, once we permanently move to a newer Java version we can ask them to change it for us.

I think it's enough to just match the name, I don't know if it needs any steps or not.

[hmottestad]

Maybe it's just the space before (11) that is wrong?

[fkleedorfer]

with the job 'build' that has strategy/matrix configuration containing '11', it works.

[fkleedorfer]

Now all that's failing is the slow-tests job. Should we give it more than 6 hours?

[fkleedorfer]

The develop branch has the same problem - but only when building with java 17:

[fkleedorfer]

@hmottestad let me know if you think there is anything more I can do here

[fkleedorfer]

@hmottestad if I wanted to raise the chance that this makes it into the next release, what would you recommend I should do?

[hmottestad]

I believe it'll have to wait for the next major release. Last we looked into this we ran into issues with Elasticsearch, Solr and Lucene needing to be upgraded too. And Elasticsearch needs a massive rewrite if we want to upgrade it since they changed their license to one that is incompatible.

You can start with formatting the code, and then running the license tool to see what we need to do for IP work.

[fkleedorfer]

ok, will do!

[hmottestad]

Let me look at the dependency tree. Want to see how the conflicts look when Solr, Elasticsearch and Lucene are included.

[fkleedorfer]

My goal with this PR was to enable building spring-boot applications that have an RDF4J storage back end, both with old and new spring-boot dependencies. The dependencies are changed for those rdf4j submodules that require it, but not for just any module's dependencies. Consequently, I think any module unchanged by this PR should continue to work as before, using old spring-boot and related libs. Only people who choose to use both (make a spring-boot 3 app using RDF4J and use old libs) will have to sort out library conflicts.

So, while now is as good a time as ever to migrate everything, it is also an option to just merge this PR and allow people to start working with spring-boot 3 if their setting allows it. There are projects like that out there.

Having said that, someone would have to verify the unchanged modules in the tools folder (mentioned in the PR description), just to check that nothing went wrong, but they were not touched and should work as before.