Skip to content

ADR: Strategy for Core-Common Migration to Spring 6 and Jakarta EE

ADR: Strategy for Core-Common Migration to Spring 6 and Jakarta EE

Status

  • Proposed
  • Trialing
  • Under review
  • Approved
  • Retired

Context

Our current challenge revolves around the compatibility of Core-Common with Spring 6 and Jakarta and the breaking changes caused by the Core-Common upgrade that will affect OSDU services that will keep using Spring 5 and Javax. The same issue is observed with CSP core-libs.

Problem Statement

If we proceed with upgrading Core-Common to Spring 6 and Jakarta as is, services on Spring 5 won't be able to use the upgraded Core-Common. This also applies to CSP core-libs. Freezing the service with the old Core-Common is not a viable option.

Example of straightforward, not compatible migration: !261 (closed)

Decision Options

1. Fork of Core-Common

Create a new branch or module within the same repository to maintain a second version of Core-Common. Two versions of Core-Common will have to be maintained simultaneously.

  • Pros: Less initial development effort is required. Ability to add new breaking changes to Core-Common fork.
  • Cons: This approach will require cherry-picking changes, potentially increasing maintenance overhead.

2. Byte/Source Code Modifications during Build

Modify code during the build process using plugins.

  • Pros: Possibility of a smooth upgrade, no changes would be required for services that are still using Spring 5 and Javax.
  • Cons: This workaround may introduce potential build and runtime issues, and its feasibility is uncertain. Requires a lot of initial effort to develop complex build configurations.

3. Heavy Core-Common Refactoring

Refactored Core-Common, 2 new modules with extracted affected code, 1 compatible with Spring 5 and Javax, and another for Spring 6 and Jakarta.

  • Pros: Cleaner approach, compatibility will be guaranteed, lesser chance of unexpected issues.
  • Cons: A lot of effort to refactor. Breaks the current flow, auto upgrades could be blocked, it may be required to switch libraries. Code duplicates are possible, so in further development, we may have to push changes into two modules.

Decision

TBD

Consequences

TBD