Migrate to Spring Boot 4, Jackson 3, and modern build tooling

[v3rm0n]

What & why

Completes the Spring Boot 4 migration on this branch and gets the full build green — compile, SpotBugs, Checkstyle, Shadow jar, and all integration tests — on Gradle 9 / Java 25. As a deliberate part of the migration, Jackson is moved from 2.x to 3.x (tools.jackson).

Builds on the existing Upgrade Gradle commit already on this branch.

Changes

Build tooling

• Shadow plugin johnrengelman 8.1.1 → gradleup 9.4.2 (the old fork calls the removed FileCopyDetails.mode on Gradle 9); rewrote the protobuf dependency filter for the new API.
• SpotBugs plugin 6.0.2 → 6.5.5, pinned tool 4.9.8 so it can read Java 25 class files (major version 69).
• Pinned the Checkstyle tool to 10.24.0. It was following the Gradle version's default, so the Gradle 9 upgrade silently changed which rules are enforced — that is why the sendMessage overloads in ITransactionalKafkaMessageSender had to move next to each other (OverloadMethodsDeclarationOrder). Pinning keeps rule changes a deliberate edit rather than a side effect of a build tool bump.
• Pinned a Temurin 25 toolchain (plus mise.toml and the foojay resolver) so main compilation no longer depends on whichever JDK happens to run Gradle.
• Compile with --release rather than only -source/-target. With a JDK 25 toolchain, -target 17 pins the bytecode version but still lets javac link against JDK 25 APIs; --release makes the API surface match what we publish for. Tests continue to compile and run on Java 17.

Spring Boot 4

• Added spring-boot-kafka (KafkaAutoConfiguration was split out of spring-boot-autoconfigure).
• Updated Flyway/Validation autoconfigure imports to their new split-module packages (org.springframework.boot.flyway.autoconfigure.*, org.springframework.boot.validation.autoconfigure.*).
• spring-boot-flyway and spring-boot-validation are compileOnly. They exist only to satisfy the FlywayAutoConfiguration/ValidationAutoConfiguration references in @AutoConfigureAfter, which Spring resolves from bytecode metadata and tolerates being absent. As implementation they would put flyway-core on the runtime classpath and in the published POM, so Flyway auto-configuration would activate in every consuming service and create flyway_schema_history in databases that never opted into Flyway. The test application and the demoapp do run migrations, so they declare spring-boot-flyway directly.

Jackson 3

• Switched jackson-databind from com.fasterxml.jackson.core to tools.jackson.core and migrated every ObjectMapper import to tools.jackson.databind. JsonMapper extends ObjectMapper, so the call sites (writeValueAsBytes, readValue) are unchanged.
• This is a breaking change for consumers: tw-tkms-starter now requires Jackson 3 on the runtime classpath.

Dependencies

• lz4-java moved from the abandoned org.lz4 coordinate to the maintained at.yawk.lz4 fork (1.10.1). This is not a free choice — kafka-clients 4.1.2 already depends on at.yawk.lz4:lz4-java:1.10.1, and both artifacts ship the same net.jpountz.lz4 packages, so keeping org.lz4:lz4-java:1.8.0 would put duplicate classes on the classpath with no version conflict for Gradle to resolve.

SpotBugs findings

• Removed three now-useless @SuppressFBWarnings (rules no longer triggered).
• Fixed a real concurrency bug: TkmsRegisteredMessagesCollector.enabled is now volatile.
• Broadened the generated-proto exclusion to the StoredMessage inner classes.

Test infrastructure

• Replaced EOL wurstmeister/kafka:2.12-2.4.1 (its docker-in-docker port trick breaks on the current Docker API) with bitnamilegacy/kafka:3.6.0 using static port mappings.
• KafkaConfiguration.createTopic now waits until topic metadata has fully propagated (every partition has an elected leader) before returning, fixing a startup topic-validation race that flaked under full-suite load.

CI

• Build matrix reduced to Spring Boot 4.0.6; 3.4.6/3.5.0 can no longer resolve the SB4-only artifacts or Jackson 3.
• Kafka service containers moved to bitnamilegacy/kafka:3.6.0 with explicit KAFKA_CFG_ADVERTISED_LISTENERS (wurstmeister auto-derived them).
• Dropped the gradle-version: 8.5 pin on the Setup Gradle steps. The wrapper (9.5.1) is what actually executes every arguments: step, so 8.5 was provisioned and discarded on every run.

Distribution

• Version becomes 0.36.0-ly.1. Upstream has already tagged v0.36.0 (never published — Central stops at 0.35.0), so a plain 0.36.0 would risk two different jars under identical coordinates, resolved by repository order. Consumers pin the version explicitly, so the suffix only has to be unique, not sort above upstream.
• Added a manually-triggered Publish workflow that pushes both tw-tkms-starter and tw-tkms-test-starter to GitHub Packages. The existing publishing config already reads MAVEN_URL/MAVEN_USER/MAVEN_PASSWORD, so this needed no build changes — just a workflow supplying them from the built-in GITHUB_TOKEN. It runs publishAllPublicationsToMavenRepository, not publish, which would also attempt Sonatype and fail on absent SONATYPE_* credentials.
• Manual trigger is deliberate: GitHub Packages rejects re-publishing an existing release version, so firing on every master push would fail after the first, and tags created by tagRelease cannot trigger workflows because they are pushed with GITHUB_TOKEN.

Verification

./gradlew build --rerun-tasks passes: 113 tests, 0 failures, 3 skipped, plus SpotBugs, Checkstyle, Shadow jar and publishToMavenLocal.

Confirmed the dependency-scope change end to end: flyway-core is gone from :tw-tkms-starter:runtimeClasspath and from the generated POM, while the test suite still exercises Flyway through FlywayAutoConfiguration. Also verified javac receives --release 17 and that the emitted class files are major version 61.

Exercised the publish path against a local HTTP Maven stand-in: both modules upload jar + POM + sources + javadoc at 0.36.0-ly.1 under com/transferwise/kafka/, with basic-auth credentials applied to every request. The uploaded POM carries tools.jackson.core, at.yawk.lz4 and spring-boot-starter-validation, and no Flyway.

Consumer migration

Backend already depends on com.transferwise.kafka:tw-tkms-starter and tw-tkms-test-starter, pinned to 0.35.0 via io.spring.dependency-management, and is on Spring Boot 4.0.7 — so it can take this. To switch it over, add the GitHub Packages repository (Maven reads there require authentication even for public packages, so every dev machine and CI job needs a read:packages token) and bump the pinned version to 0.36.0-ly.1.

Reviewer notes

• This targets lightyeardev:master (the fork), not upstream transferwise.
• Local runs need the Colima VM at ≥6 GiB (the default 2 GiB OOM-kills a Kafka broker mid-suite); not a repo change, just an env note.

Known test-infrastructure rough edges (pre-existing, not addressed here)

• dockerCompose.stopContainers = false means the Kafka containers survive between runs, and a restarted bitnamilegacy/kafka container exits immediately without logging. A stale container from an earlier run makes the whole suite fail with TimeoutException ... Call: deleteTopics; ./gradlew composeDownForced clears it.
• waitForTcpPorts = false means the first run against fresh containers can start before MariaDB accepts connections, failing every test through a single poisoned Spring context. Re-running once the containers are warm passes.
• bitnamilegacy/* images are an archived, no-longer-patched line, so this swaps one unmaintained image for another. Moving to the official apache/kafka images would also mean dropping ZooKeeper for KRaft — worth doing separately.
• The compose Kafka brokers now bind host ports 9092/9093 statically (the advertised listener has to name a port known up front), so a local Kafka on either port will block the suite. Everything else in the compose file still uses dynamic ports.

🤖 Generated with Claude Code