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