GN4 SpringFramework 6 OpenRewrite Update

[jodygarnett]

Based on the positive GeoServer 3 experience of upgrading to Spring Framework 6 this proposal recommends this approach for the core-geonetwork codebase.

Two things have changed since the initial feasibility exploration and proposal:

• Tools, specifically OpenRewrite have lessened the effort required to update to Spring Framework 6; and
• Many of the libraries used by GeoNework have now released JakartaEE compatible versions making migration possible

Assessment:

• @jodygarnett and @davidblasby carried out an assessment specificly of using the OpenRewrite tools, based on the GeoServer 3 experience, to determine if this activity was technically feasible and to identify fundamental blockers (such as a library incompatibility).
• While the result spring6-try3 compiles, it in no way attempts to startup with new configuration required for jetty and activemq among others.
• Importantly the XmlTest shows that our patched Saxon 8.x fork continues to operate, although And XslConversionTest shows unit test covering the use of Java Functions!

Risks:

• Resource commitment (sponsorship and in-kind) for this activity
• Spring Framework 7 is now scheduled for April of 2026 (Spring Framework 6 reaches EOL in April).
• This approach is a lift-and-shift updating dependencies in place and adapting to api changes. For anything beyond this approach GN5 and SpringBoot is the preferred approach. Some libraries have discontinued (keycloak) or heavily modified (activemq)
• We cannot continue to ship GeoNetwork 4.2.x and 4.4.x on outdated version of Spring Framework 5.3 (see "why this is important" below).

Why is this important

With Cyber Resilience Act coming into effect in 2026 and 2027 the GeoNetwork project can no longer expect to make releases with known security vulnerabilities, or using components with known security vulnerabilities. These updates are required to be performed of any new features or improvements.

Project policy must adjust to reflect the increased expectations, and associated operational expenses, for open source development.

Proposal Support

Those with developer resources can contribute directly. For more information funding this activity look at commercial support options, or GeoNetwork-2026-Sponsorship-Opportunities to coordinate funding across several parties.

[davidblasby]

Here is my feedback (and some notes) - based on my experience attempting to upgrading GN to spring 6.

1. We only looked at spring 5->6 (which is end of life in a few months), we also need to do spring 6 -> 7
2. A lot of the "other" libraries needed to be upgraded, and then their dependencies would need to be upgrades, etc...
3. Many of the library upgrades had major API changes - likely needed some re-working inside GN. I also noticed that default values/functionality had changed in the library.
4. Getting things to "compile" (the openrewrite scripts) wasn't too bad.
5. We didn't get many tests to successfully run
6. The ActiveMQ, with its change from Classic to Artemis was a bit difficult, as well as from javax to jakarta was difficult (still in progress). This also has a big impact on camel. We didn't resolve this.
7. I found that not having an extremely good understanding of the GN code, an extremely good understanding of the old libraries (and their dependencies/configuration), and an extremely good understanding of the new libraries (and their dependencies/configuration changes as well as API changes) makes a lot of the work "along the lines of guessing with no real checks to see if its working".
8. Moving from "compiling" to "running" is probably a lot of work. Moving from "running" to "production" is likely a tonne of work.
9. Doing this and allowing changes on GN4 main is probably not reasonable.
10. It would be nice to transition to spring-boot, but that is probably too difficult (probably better to just go to GN5).
11. Might make sense to fully segment the GN4 webapps. They are "partial" separated, already, in GN4 and startup at different times. I think a search, admin, harvest, and edit would be an appropriate split. This would allow better security were the search would be more open the public (and deployed separately) than the edit. The search/harvest could, eventually be replaced with GN5 (ogcapi-records part 1, 2, and 3).
12. Are there enough resources (people with a good understanding of GN4) to actually do the work in a reasonable amount of time?
13. I think this project has a very large risk and is expensive - could cost a lot and fail.