Skip to content

Derive the JUnit platform version from JUnit.version - #758

Merged
alexander-yevsyukov merged 1 commit into
masterfrom
junit-platform-version-reference
Sep 3, 2026
Merged

Derive the JUnit platform version from JUnit.version#758
alexander-yevsyukov merged 1 commit into
masterfrom
junit-platform-version-reference

Conversation

@alexander-yevsyukov

Copy link
Copy Markdown
Contributor

Problem

JUnit.Platform.version held the JUnit version as its own literal:

object JUnit : DependencyWithBom() {
    override val version = "6.1.3"
    ...
    object Platform : Dependency() {
        override val version: String = "6.1.3"   // repeated

Every JUnit bump therefore had to be applied twice. The latest bump to 6.1.3
was applied to both, but nothing enforced that — the two could drift silently,
and the platform artifacts would then be pinned off the BOM's line.

Fix

Read JUnit.version instead. JUnit.Jupiter.version already does exactly
this, so Platform now matches the sibling declared a few lines above it.

Why this is safe

JUnit 6 unified the platform and Jupiter version lines. Verified directly
against Maven Central: junit-bom:6.1.3 declares
junit-platform-launcher:6.1.3, and that artifact resolves (HTTP 200).

This was not true under JUnit 5, where the platform was 1.x while
Jupiter was 5.x. The KDoc now records that history, so the next reader does
not have to rediscover why tying the values together is correct now and would
have been a bug before.

No version changes: both sides were already 6.1.3.

Verification

  • ./gradlew detekt — BUILD SUCCESSFUL.
  • dependency-audit — APPROVE. It also confirmed there is no Kotlin
    object-initialization-order hazard in reading JUnit.version from the
    nested Platform object, and found no consumer reading
    JUnit.Platform.version directly.

Where this came from

Reported by Copilot on
jdbc-storage#183.
buildSrc/src/main/kotlin/io/spine/dependency/** is config-distributed, so
jdbc-storage only carries the overlay — the fix belongs here.

🤖 Generated with Claude Code

`JUnit.Platform.version` repeated the JUnit version as a literal, so a
JUnit bump had to be applied in two places. The most recent one, to
`6.1.3`, happened to be applied to both; nothing enforces that.

`JUnit.Jupiter.version` already reads `JUnit.version`, so this only makes
`Platform` follow the sibling it sits next to.

Safe because JUnit 6 unified the two version lines: `junit-bom:6.1.3`
declares `junit-platform-launcher:6.1.3`. Under JUnit 5 they genuinely
differed — the platform was `1.x` against Jupiter's `5.x` — so the KDoc
now records why the values may be tied together.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 2, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-02T18:42:22.049674Z 105f78f PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@alexander-yevsyukov alexander-yevsyukov self-assigned this Sep 2, 2026
@alexander-yevsyukov alexander-yevsyukov moved this to 🏗 In progress in v2.0 Sep 2, 2026
@alexander-yevsyukov alexander-yevsyukov moved this from 🏗 In progress to In Review in v2.0 Sep 2, 2026
@alexander-yevsyukov
alexander-yevsyukov merged commit 070a1a6 into master Sep 3, 2026
2 checks passed
@alexander-yevsyukov
alexander-yevsyukov deleted the junit-platform-version-reference branch September 3, 2026 09:38
@github-project-automation github-project-automation Bot moved this from In Review to ✅ Done in v2.0 Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

2 participants