Skip to content

GeoNetwork 5 evolution roadmap codesprint July 2024

Jeroen Ticheler edited this page Aug 29, 2024 · 4 revisions

When & Where?

  • 22 to 24 July
  • The sprint will be online

Participants

  • Jose
  • Francois
  • Juan
  • Jody

Sponsors

Agenda

GeoNetwork 4 is facing challenges due to maintenance of some of the core libraries.

On the server side, Spring 5 is maintained until the end 2024 and supports up to Java 11. To add support for Java 17+, a migration to Spring 6 has to be planned. As a consequence, this also requires updating all core libraries like Saxon, Hibernate, WRO4J, Sesame …

This is a proposal to draw a global roadmap to design GeoNetwork 5.

Main goal of this sprint is to finalize a first draft proposal and investigate some of the technical issues to cope with.

Proposed draft agenda:

  • proposal review & feature migration strategy
  • project setup review (pom, license, formatting, checkstyle)
  • authentication (how to share auth between the 2 apps?)
  • test (how to start GeoNetwork and Elasticsearch for test? testcontainer, mock)
  • project packages (modulith or not)
  • schema & schema plugins (how to move this? formatters, xslt, ...)
  • tasks orchestrator (what to use?)

Proposal

2 main options:

  • a) Update and migrate the current application from Spring 5 to Spring 6
  • b) Create a new application on top of current GeoNetwork

if a)

  • (-) unsure if we can really update to Spring 6 as all dependencies needs to be updated too (eg. we know that the encryptor dependency is not maintained anymore)
  • (-) require good knowledge of everything

if b)

  • (+) easier to do it step by step
  • (+) require less knowledge about GeoNetwork (can be done on a per feature basis)
  • (+) start from scratch so easier to clean up everything, better testing
  • (-) will require 2 apps to run in parallel

The choice of starting a new application is made in order to take this as an opportunity to clean up, improve and simplify the current codebase. Option b) sounds preferable.

The main goal is to design a new application able to communicate with the existing server component and define phases to transition functionalities from core-geonetwork to a new framework based on Spring Boot 3 and Spring 6.

While moving functionalities, the community can discuss what needs simplification, rework or removal.

Transition scenario:

image

image

Whats next?

Write a proposal.

Related work

Clone this wiki locally