GN4 Spring 6 breakout meeting

Attending:

• Jody Garnett (GeoCat)
• David Blasby (GeoCat)
• Sebastien Riollet (Camptocamp)
• Pierre Mauduit (Camptocamp)
• François Van Der Biest - Camptocamp - Project manager
• Tanzeela de Bont (GeoCat)
• Antonio Cerciello (GeoCat)

Agenda:

1. Introduction
2. OpenRewrite Findings (2025)
3. Scope
4. Resource Commitment
5. Proposal / should we attempt?
   1. Potential problems
   2. Opportunity costs

Introduction

Breakout meeting from GN5 meeting, can we leverage the positive GS3 experience using OpenRewrite scripts that automates a lot of the boiler plate activities associated with updating libraries: springframework, jakarataEE, and so on …

Reference:

• Geonetwork-on-Spring-6-codesprint-June-2023 (previous attempt)

module	compile	test	qa
GeoNetwork opensource	SUCCESS
GeoNetwork common utils	SUCCESS
Caching xslt module	SUCCESS
ArcSDE module (dummy-api)	SUCCESS
GeoNetwork domain	SUCCESS
Oaipmh modules	SUCCESS
GeoNetwork Events	SUCCESS
GeoNetwork schema plugins	SUCCESS
GeoNetwork schema plugins core	SUCCESS
GeoNetwork schema plugin for ISO19139/119 standards	SUCCESS
GeoNetwork schema plugin for ISO19115-3:2018 standard	SUCCESS
Index module	SUCCESS
GeoNetwork core	FAILURE
GeoNetwork Listeners
GeoNetwork schema plugin for Dublin Core records CSW	SUCCESS
GeoNetwork schema plugin for Dublin Core standard	SUCCESS
GeoNetwork schema plugin for ISO19110 standard	SUCCESS
GeoNetwork CSW server
GeoNetwork harvesters
GeoNetwork health monitor
GeoNetwork Digital Object Identifier (DOI) client
GeoNetwork translation providers
GeoNetwork auditable objects
GeoNetwork services
Geonetwork Web Resources 4 Java
GeoNetwork INSPIRE Atom
GeoNetwork index using Elasticsearch	SUCCESS
GeoNetwork dashboard app based on Kibana	SUCCESS
GeoNetwork user interface module	SUCCESS
gn-messaging	FAILURE
gn-workers	SUCCESS
WFS features harvester
gn-camel-periodic-producer
GeoNetwork Web module
GeoNetwork Release module
gn-es-test
GeoNetwork datastorage providers	SUCCESS
GeoNetwork Plugins	SUCCESS
GeoNetwork Slave
Tests for schema plugins

OpenRewrite Findings

During the first part of the week David and Jody took an attempt at this so the meeting would be productive:

• Took 3 or 4 attempts
• Goal was to make a table, showing what modules compile / pass tests / work
• Was not successful, but that is fine!

Attempts:

1. SpringFramework 6 update
   Failed as it did not include JarkataEE, which means that the maven compile would not work, which means we could not run OpenRewrite again.
   1. HTTP-Client 4 → 5 update causes compile errors
      1. version 4 and 5 use different package names
2. Attempt number performs both Spring and JarktaEE at the same multi-module run

Sebastian:

• on another project, went to SpringFramework 7 1st, fixed all the compilation errors, then upgraded security which implied to change to JakrataEE hence move to Tomcat 10

Number of libraries that need to be updated is significant here:

• Hibernate
• echache -> no direct replacement for hibernate use of this? It is now a configuration spring option

Output:

• Some work is required before to proceed in this direction (Hibernate refactor/upgrade manually).
• Need for a proposal of this work for a sponsor

• https://github.com/geonetwork/core-geonetwork/tree/spring6
  got stuck on JakarataEE
• https://github.com/geonetwork/core-geonetwork/tree/spring6-try2
  got stuck on hibernate
• https://github.com/geonetwork/core-geonetwork/tree/spring6-try3
  this is stuck on domain and hibernate!

Scope

• Update the dependencies and libraries as much as possible first
  • This is work that can be identified and funded independently
• Plan a code sprint (online?) for the cut over
• Hand over to community for testing

Discussion:

• Pierre: Perhaps we could drop direct use of Servlet / Jeeves first to make the lift less?

  • Huh if we do that kind of thing – we are back to GN5 🙂
    Which is a clean SpringBoot implementation…

• Antonio: Untangle domain code gen into interface → gen → classes

  • Jody: I hope we can see what is broken when annotations fixed

• David: Making and testing a new release (total cost) is a huge cost (example 1 year)

  • Jody: yes we cannot dedicate tester to this for a year, as was done for GN4.2, would need SHARE this cost with community (not just companies but the users)
  • aside: This may be urgent for the community when spring framework 6 EOL?

• David: Need some access to GN4 experts to do this activity!

  • Jody: was hoping this would be a java + build activity
  • David: Needed some understanding of what was going on when changing between abstract base classes and so on.
    Need access to Jose and Francois to answer be questions (at least).

• Jody: If we focus on the "code complete" aspect, to have something ready for community testing

  • Timebox this, if the scope can be < 4 weeks than we have a proposal
    Beyond this amount the effort should be abandoned and focused on GN5
    (as Pierre indicates a fresh spring only start).
  • David feels this is not realistic without access to Jose and Francois as above

• Sebastian: In position to feel comfortable because of testing that has been implemented at camptocamp

  • Having good success with automated testing on metadata101 plugin
  • Jody: Oh yeah Camptocamp just did that for GeoServer using a python acceptance tests, see example here: https://github.com/geoserver/geoserver/blob/main/.github/workflows/acceptance.yml

• Sidebar on testing:

  • Sebastian asks for a multi-lingual ISO 19115-3.2018 → Discourse channel

• Sebastian: Risk if not all the community of developers are in this then Sebastian needs to access the risk

  • Not sure there is much alternative? GN5 is not appearing easily in 2026 (migration is not an option at this time etc…)
  • Any word on GN5 and SpringBoot 4? Presently using 3.3

Proposal

Should we do a proposal?

• Technically this is possible, but the old libraries do not make this easier at all
• Establish scope needed
  • Complete the annotations and get domain to compile → to get a table of work then YES
  • If Saxon 8 can be used then —> YES
  • However: Saxon 8 → Saxon HE: If this is required then we are in a super awkward spot
    • Probably too much work to expect to complete Spring Framework 6 update in a timeline to meet the objective → NO
    • However work done on this activity directly helps / needed for GN5
      → MAYBE
  • Spring Security: This can be looked at (david did the OIDC work for GN4 already, and keycloak client is now maintained a bit longer) → MAYBE
• Opportunity Cost (see below) → MAYBE
  • Effort spent here takes resources away from long term solution (of GN5)
    • Time spent here is not available for consulting work and other income
    • Yes this needs to be a significant sharing across companies and community
    • Also this would take away form GN5 sponsorship
    • Needs to be a shared activity
• Jody: If this a three month activity, and brings codebase into a spot easier for GN5, and have solid collaboration to get this resourced → YES

If that is all good make a proposal for the GN4 board:

• Indicating this a sponsorship opportunity for GeoNetwork 2026
  (OSGeo does an annual call out)
• Folks in this meeting can socialize with their employer

Action:

• This week: try and fix domain → get table of work
  • See if we are stuck on Saxon
    • indexing is a good test of saxon
    • editor is a good test of saxon
  • If these are okay then we can make a proposal to address the "maybe" line items above