chore: upgrade Gradle to 9.4.0

[rustyrazorblade]

Upgrades Gradle from 8.12.1 to 9.4.0 to support the shadow plugin 9.x (com.gradleup.shadow).

• Update Gradle wrapper to 9.4.0 (latest stable)
• Consolidate repository declarations to dependencyResolutionManagement in settings.gradle
• Add mavenLocal() to settings for cassandra-analytics local builds
• Remove redundant project-level repository blocks

Closes #558

Generated with Claude Code

[claude]

Code Review

This is a clean, well-scoped upgrade. The consolidation of repository declarations into dependencyResolutionManagement is the correct approach for Gradle 9.x, which restricts allprojects { repositories {} } in favor of centralized resolution management. Overall the change looks good. A few things worth noting:

Potential Issue: mavenLocal() scope expanded

Previously mavenLocal() only appeared in spark/build.gradle.kts, so it only applied to the Spark subprojects (which need cassandra-analytics local builds). Now it is in dependencyResolutionManagement, which means it applies to all subprojects including the root project.

This is probably intentional (the PR description says 'Add mavenLocal() to settings for cassandra-analytics local builds'), but it is a behavior change worth being explicit about. The cassandra-analytics artifacts are only consumed by the spark/ modules. If the root project does not need local Maven resolution, scoping with a filter might be worth considering, though in practice this is a minor concern for a dev tool.

There is also a mild security note: mavenLocal() listed first means local artifacts shadow mavenCentral(). In CI this is fine since ~/.m2 is typically empty, but worth being aware of.

Missing: gradle-wrapper.jar update

When upgrading the Gradle wrapper, the binary gradle/wrapper/gradle-wrapper.jar should also be updated alongside gradle-wrapper.properties. The wrapper JAR bootstraps Gradle and ideally matches the target version. Typically done by running ./gradlew wrapper --gradle-version 9.4.0. If this was already done and the jar was committed, great. If not, it is worth adding to avoid subtle bootstrapping issues.

Minor: distributionSha256Sum

For reproducible/verified builds, gradle-wrapper.properties can include a distributionSha256Sum checksum. validateDistributionUrl=true only checks the URL format, not the integrity of the downloaded distribution. Pre-existing issue, not introduced here.

The core change is correct

The removal of allprojects { repositories { mavenCentral() } } from build.gradle.kts is the right migration for Gradle 9.x, which enforces dependencyResolutionManagement as the single source of truth for repository declarations.

[claude]

Code Review

This is a clean, minimal PR. The approach is correct and the changes are focused.

What looks good

• Consolidating repositories into dependencyResolutionManagement in settings.gradle is the correct modern Gradle pattern. This is actually required/preferred in Gradle 7+ and is the right way to centralize repository declarations for multi-project builds.
• mavenLocal() is correctly placed before mavenCentral() to prefer locally-built cassandra-analytics artifacts over remote ones.
• Removing the redundant allprojects { repositories {} } block from build.gradle.kts and the repositories block from spark/build.gradle.kts is a clean consolidation — no behavior change, just less duplication.

Minor observations

Import still uses old package name (build.gradle.kts:1)

import com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar

Shadow plugin 9.x (com.gradleup.shadow) maintains backward compatibility with the old com.github.jengelman package name, so this will still compile. But since this PR is the upgrade enabling shadow 9.x, it may be worth updating the import to com.gradleup.gradle.shadow.tasks.ShadowJar for consistency. Not blocking.

No explicit repositoriesMode
The dependencyResolutionManagement block doesn't set a repositoriesMode. The default is PREFER_SETTINGS, which is fine since all project-level repository declarations have been removed. Being explicit could prevent accidental re-introduction of project-level repos later:

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        mavenLocal()
        mavenCentral()
    }
}

Again, not blocking — just a note.

Summary

The change is correct and safe. No bugs, no security concerns, and no test changes are needed for a build tooling upgrade. The consolidation of repository declarations is the right approach for Gradle 9.

[claude]

Code Review

Overall this is a clean, well-scoped upgrade. A few observations:

Good

• Repository consolidation to dependencyResolutionManagement in settings.gradle is the correct Gradle 7+ pattern and works well with Gradle 9.
• useJUnitPlatform() on integrationTest — this is a real bug fix. Without it, JUnit 5 integration tests were silently not discovered. Worth noting this means integration tests may have been quietly not running before.
• junit-platform-launcher in spark/common — required for standalone JUnit 5 test execution under Gradle 9, correct fix.

Minor Issues

repositoriesMode not set — since repository declarations are now centralized in dependencyResolutionManagement, consider adding:

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        mavenLocal()
        mavenCentral()
    }
}

Without this, any future repositories {} block added at the project level will silently override the centralized config. FAIL_ON_PROJECT_REPOS enforces the centralized approach and prevents accidental bypasses. This is a "nice to have" but makes the intent explicit and protects against future drift.

mavenLocal() ordering — placing mavenLocal() before mavenCentral() means local artifacts always take precedence over Central. This is intentional for the cassandra-analytics local builds, but worth being aware of in CI environments. If CI doesn't have the local artifacts, it falls through to Central as expected. Low risk given this is a dev/test tool.

Stale buildscript block — build.gradle.kts still has:

buildscript {
    repositories {
        mavenCentral()
    }
}

This is separate from dependencyResolutionManagement (it's for build script classpath, not project deps) so it's not wrong. But since the plugins are all resolved via the version catalog, this block may be unnecessary. Not a blocker.

Leftover blank lines in gradlew/gradlew.bat — After removing the CLASSPATH= variable, there are double blank lines left. Cosmetic only, and these are generated files, but it's a minor template artifact.

Summary

The core changes are correct and necessary. The useJUnitPlatform() fix alone makes this worth merging. Suggest considering FAIL_ON_PROJECT_REPOS as a follow-up if not now.

[claude]

test comment

[claude]

---

PR Review: Gradle 9.4.0 Upgrade

Overall this is a clean, well-scoped upgrade focused on what Gradle 9 requires without unnecessary scope creep.

Positive changes worth calling out:

• useJUnitPlatform() on integrationTest: This was a latent bug; Gradle 9 stricter test engine validation would surface it. Good catch.
• Repository consolidation to dependencyResolutionManagement: Correct approach for Gradle 9; project-level repositories {} blocks are deprecated.
• gradlew / gradlew.bat updates: Standard generated wrapper changes (SPDX header, -jar invocation instead of -classpath). These look correct.

Minor issues:

1. spark/common/build.gradle.kts uses string notation instead of the version catalog. The alias libs.junit.platform.launcher was just added in libs.versions.toml and should be used here for consistency and to avoid version drift: use testRuntimeOnly(libs.junit.platform.launcher) instead of the hardcoded string.

2. junit-platform-launcher has no version pin in the catalog. The new entry has no version.ref, relying on BOM-managed alignment with junit-jupiter. That is acceptable since they share the same JUnit 5 BOM, but adding version.ref = "jupiter" would make the intent explicit and prevent accidental mismatches if the BOM changes.

3. Trailing blank lines in gradlew / gradlew.bat after removing the CLASSPATH variable assignments. Cosmetic only.

No concerns on:

• mavenLocal() ordering (first in settings) -- correct for resolving cassandra-analytics snapshots before hitting remote
• Removal of the project-level allprojects { repositories {} } block -- correct for Gradle 9 compliance
• Spark subproject repository block removal -- now covered by dependencyResolutionManagement

---

[rustyrazorblade]

@claude diagnose the error, what is wrong here?

[claude]

Claude finished @rustyrazorblade's task in 2m 36s —— View job

---

Diagnosis

• Check CI status
• Identify failing job(s)
• Download and analyze logs
• Report findings

---

Root Cause: Kover now triggers integrationTest as part of koverXmlReport

The failing task is :integrationTest, which fails with:

> Process 'Gradle Test Executor 4' finished with non-zero exit value 2

What's happening:

The CI runs ./gradlew test koverXmlReport, and the koverXmlReport task is now automatically picking up and executing the :integrationTest task to collect coverage data. The integrationTest task contains MainTest.basicTest(), which is a full end-to-end test that tries to create real AWS infrastructure:

// src/integration-test/kotlin/com/rustyrazorblade/easydblab/MainTest.kt
fun basicTest() {
    main(arrayOf("init", "easy-db-lab", "no ticket", "automated test suite", "-s", "1"))
    main(arrayOf("up", "--yes"))   // ← tries to spin up real AWS cluster
    ...
}

Why this is new (introduced by this PR):

Commit bb19227 Fix Gradle 9 test discovery issues added useJUnitPlatform() to the integrationTest task. Once useJUnitPlatform() is set, Kover 0.9.4 recognizes it as a JUnit test task and automatically includes it in coverage collection — which means koverXmlReport now triggers it. Before this change, the task wasn't recognized by Kover and was silently skipped.

The fix:

Exclude integrationTest from Kover instrumentation in build.gradle.kts. The Kover 0.9.x API for this is:

kover {
    currentProject {
        instrumentation {
            excludedTestTasks.add("integrationTest")
        }
    }
    // ... rest of existing kover config
}

This tells Kover not to instrument or run integrationTest as part of coverage tasks. The task can still be run manually for real end-to-end testing against AWS.
|

[claude]

PR Review: Gradle 9.4.0 Upgrade

Overall this is a clean, well-scoped upgrade. The consolidation of repositories into dependencyResolutionManagement and the addition of useJUnitPlatform() to the integration test task are both correct for Gradle 9. A few things worth discussing:

---

1. buildscript block in build.gradle.kts (lines 3–7) — likely redundant

buildscript {
    repositories {
        mavenCentral()
    }
}

This block predates the dependencyResolutionManagement approach and is now redundant since plugins are resolved via the settings-level repository configuration. In Gradle 9, plugin classpath resolution uses the pluginManagement block in settings (or defaults). This buildscript block can likely be removed to keep things clean.

---

2. bin/easy-db-lab — silent removal of auto-build behavior

The removal of the auto-build block is a notable developer experience change:

# Removed:
if [ "${EASY_DB_LAB_SKIP_BUILD}" != "1" ]; then
    "${APP_HOME}/gradlew" -p "${APP_HOME}" shadowJar installDist -q
fi

Previously, running bin/easy-db-lab would always produce a fresh build unless EASY_DB_LAB_SKIP_BUILD=1 was set. Now, if the JAR doesn't exist or is stale, the script will fail with a cryptic "JAR not found" or "class not found" error. If this is intentional (e.g., for startup speed), it should be documented somewhere (README/dev docs), and a useful error message should be added when the JAR is missing:

if [ ! -f "$JAR" ]; then
    echo "Error: JAR not found at $JAR. Run './gradlew shadowJar' first." >&2
    exit 1
fi

---

3. mavenLocal() order in global dependencyResolutionManagement

mavenLocal() is now first in the global repository list, which means it takes precedence over Maven Central for all projects (root + all spark subprojects). This was previously scoped only to spark subprojects. While necessary for cassandra-analytics local builds, it introduces a risk in CI: if any stale or unintended artifact exists in ~/.m2/repository on a CI agent, it could silently shadow the correct artifact from Maven Central.

A comment documenting why mavenLocal() is needed here would help future maintainers avoid accidentally removing it or changing the order.

---

4. spark/common/build.gradle.kts — hardcoded versions (pre-existing, low priority)

testImplementation("org.junit.jupiter:junit-jupiter:5.10.2")
testImplementation("org.assertj:assertj-core:3.25.3")

These were pre-existing and not introduced by this PR, but now that the testing bundle in libs.versions.toml has junit-platform-launcher, this module is managing its own test deps inconsistently. Not a blocker, but worth a follow-up to align spark/common with the version catalog.

---

Positives

• useJUnitPlatform() on the integrationTest task is a real fix — JUnit 5 tests would silently not run without it.
• Adding junit-platform-launcher to the testing bundle is the correct Gradle 9 approach.
• Removing duplicate repositories {} blocks from project-level build files is the right consolidation.
• The wrapper script changes (gradlew, gradlew.bat) look like standard Gradle 9 wrapper regeneration output.

[rustyrazorblade]

@claude diagnose the failures

[claude]

Claude finished @rustyrazorblade's task in 2m 7s —— View job

---

Diagnosis & Fix

• Check current CI status
• Identify failing jobs
• Download and analyze logs
• Implement fix
• Push fix

Root Cause: koverXmlReport was triggering integrationTest

The CI runs ./gradlew test koverXmlReport .... Since useJUnitPlatform() was added to the integrationTest task in this PR, Kover now recognizes it as a JUnit test task and automatically includes it in coverage collection — which causes koverXmlReport to trigger the task.

integrationTest spins up real AWS infrastructure, so it always fails in CI (no credentials). Exit code: non-zero exit value 2.

Fix applied (commit 81748bc)

Added excludedTestTasks to the Kover configuration in build.gradle.kts:

kover {
    currentProject {
        instrumentation {
            // integrationTest runs against real AWS infrastructure - exclude from coverage collection
            excludedTestTasks.add("integrationTest")
        }
    }
    reports {
        // ... existing config
    }
}

This tells Kover not to instrument or run integrationTest as part of any coverage task. The task can still be run manually for real end-to-end testing against AWS.
| Branch

[claude]

Code Review

The PR is well-scoped and the Gradle 9 migration approach is correct. Previous comments have covered most concerns. A few remaining observations:

Unaddressed: bin/easy-db-lab auto-build removal

The auto-build block was removed without explanation. If intentional, the script should fail fast when the JAR is missing rather than producing a cryptic error. The PR description does not mention this change, so it may have been unintentional.

Minor: Hardcoded dependency in spark/common/build.gradle.kts

The newly added junit-platform-launcher dependency has no version pin. It should use libs.junit.platform.launcher from the version catalog for consistency.

Core changes are correct: Gradle 9.4.0 wrapper, dependencyResolutionManagement consolidation, and junit-platform-launcher in the testing bundle are all correct for the Gradle 9 upgrade.

[github-actions]

Code Coverage

Total Project Coverage	67.03%	❌

[rustyrazorblade]

What's failing?

[rustyrazorblade]

@claude Diagnose the failure

[claude]

Claude finished @rustyrazorblade's task in 49s —— View job

---

Diagnosis & Fix

• Check current CI status
• Identify failing job(s)
• Download and analyze logs
• Fix and push

Root Cause: ktlint violation in build.gradle.kts

The quality job was failing on the ktlintCheck step with:

build.gradle.kts:154:1 Unexpected blank line(s) before "}"

There was a stray blank line inside the sourceSets block before the closing }:

// Before (invalid):
    val test by getting {
        java.srcDirs("src/test/kotlin")
    }
                          ← stray blank line here
}

// After (fixed):
    val test by getting {
        java.srcDirs("src/test/kotlin")
    }
}

Fix Applied

Removed the trailing blank line. Committed as c9b0169 and pushed to the branch.

View job | Branch

[claude]

PR Review: Gradle 9.4.0 Upgrade

The core Gradle upgrade is solid — wrapper update, shadow plugin migration to com.gradleup.shadow, junit-platform-launcher additions, and repository consolidation all look correct. A few things worth discussing:

---

🔴 Breaking: bin/easy-db-lab loses auto-build

The removal of the auto-build block is the biggest behavioral change in this PR, but it's not mentioned in the description:

-if [ "${EASY_DB_LAB_SKIP_BUILD}" != "1" ]; then
-    "${APP_HOME}/gradlew" -p "${APP_HOME}" shadowJar installDist -q
-fi

Previously, running bin/easy-db-lab would automatically build the JAR if needed. Now if the JAR doesn't exist (fresh checkout, after ./gradlew clean, etc.) the script will just fail silently. The existence of EASY_DB_LAB_SKIP_BUILD as an opt-out indicates that auto-build was the intended default behavior.

Is this intentional? If so, the docs should reflect the new requirement to run ./gradlew shadowJar before using the CLI.

---

🟡 Shadow plugin import still uses old package name

build.gradle.kts:1 still imports from the old package:

import com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar

Shadow 9.x (com.gradleup.shadow) renamed the package. The correct import is:

import com.gradleup.shadow.tasks.ShadowJar

Shadow 8.x introduced a compatibility shim, but shadow 9.x dropped it. This may cause a compile error — worth verifying CI passes with this import.

---

🟡 junit-platform-launcher hardcoded version in spark/common

In spark/common/build.gradle.kts, the launcher is added with a hardcoded version:

testRuntimeOnly("org.junit.platform:junit-platform-launcher")

This is fine since it has no version (BOM manages it), but the version catalog entry libs.junit.platform.launcher added in libs.versions.toml isn't being used here. Consider using the catalog alias for consistency with the rest of the build:

testRuntimeOnly(libs.junit.platform.launcher)

---

🟡 Removal of integrationTest source set

The integrationTest source set, its Gradle configuration, and MainTest.kt are removed. The MainTest.kt contained a meaningful end-to-end flow (init → up → use → install → start → down → clean). Was this intentionally dropped? If integration tests are being replaced elsewhere, that should be noted. If they were just broken/unused, worth a brief mention in the PR.

---

✅ Things that look good

• mavenLocal() correctly placed before mavenCentral() in dependencyResolutionManagement
• Removing project-level repositories {} blocks from build.gradle.kts and spark/build.gradle.kts aligns with Gradle 9's centralized repository management
• junit-platform-launcher added to both the version catalog and the testing bundle — required for Gradle 9's test engine changes
• gradlew/gradlew.bat changes (using -jar instead of -classpath, printf '%s\n' "$PWD") are the standard Gradle 9 wrapper improvements

[rustyrazorblade]

@claude

Address this:

Shadow plugin import still uses old package name

build.gradle.kts:1 still imports from the old package:

import com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar
Shadow 9.x (com.gradleup.shadow) renamed the package. The correct import is:

import com.gradleup.shadow.tasks.ShadowJar
Shadow 8.x introduced a compatibility shim, but shadow 9.x dropped it. This may cause a compile error — worth verifying CI passes with this import.

🟡 junit-platform-launcher hardcoded version in spark/common

In spark/common/build.gradle.kts, the launcher is added with a hardcoded version:

testRuntimeOnly("org.junit.platform:junit-platform-launcher")
This is fine since it has no version (BOM manages it), but the version catalog entry libs.junit.platform.launcher added in libs.versions.toml isn't being used here. Consider using the catalog alias for consistency with the rest of the build:

testRuntimeOnly(libs.junit.platform.launcher)

[claude]

Claude finished @rustyrazorblade's task in 37s —— View job

---

Fixing Shadow Plugin Import and Version Catalog Usage

• Read relevant files
• Fix shadow plugin import in build.gradle.kts
• Use version catalog alias in spark/common/build.gradle.kts
• Commit and push

Both changes applied in commit a5df70a:

1. build.gradle.kts:1 — Updated shadow import to the correct com.gradleup.shadow package name for Shadow 9.x
2. spark/common/build.gradle.kts:12 — Replaced hardcoded string dependency with libs.junit.platform.launcher version catalog alias

Branch

[claude]

PR Review: Gradle 9.4.0 Upgrade

Overall this is a clean, well-scoped upgrade. The changes are minimal for the version jump and the consolidation of repository declarations is the right approach for Gradle 9. A few things worth discussing:

---

Issues

junit-platform-launcher is in the wrong configuration for the root module

libs.versions.toml adds junit-platform-launcher to the testing bundle, which maps to testImplementation in the root build.gradle.kts. For Gradle 9 the launcher needs to be a runtime-only dependency — it does not need to be on the compile classpath and Gradle 9 will warn (or in some setups fail) if it's pulled in via testImplementation.

spark/common/build.gradle.kts correctly uses testRuntimeOnly(libs.junit.platform.launcher) (line 12 of that file), but the root module picks up the launcher through testImplementation(libs.bundles.testing) via the bundle.

The cleanest fix is to remove junit-platform-launcher from the testing bundle in libs.versions.toml and add explicit testRuntimeOnly(libs.junit.platform.launcher) declarations in the root build.gradle.kts and any other submodule that needs it — mirroring what spark/common already does correctly.

buildscript { repositories { mavenCentral() } } block is orphaned in build.gradle.kts

The PR removes the allprojects { repositories { ... } } block (correct under Gradle 9's dependencyResolutionManagement), but the buildscript block at the top of build.gradle.kts (lines 3–7) still declares its own mavenCentral() repository. This block is for buildscript classpath resolution and is intentionally separate, so it is technically correct — but it looks inconsistent after this change. A comment explaining why it remains would help future readers.

---

Concerns Worth Flagging

EASY_DB_LAB_SKIP_BUILD env var removed without a docs update

bin/easy-db-lab previously honoured EASY_DB_LAB_SKIP_BUILD=1 to skip the auto-build. That escape hatch is now gone — the script no longer builds at all. The README does not appear to reference this variable, so there's no user-facing documentation to update, but it is a behavioural change: anyone who relied on the auto-build triggered by running bin/easy-db-lab will now need to run ./gradlew shadowJar explicitly before using the dev script. This is probably intentional (consistent with requiring an explicit build step), but it should be mentioned in the PR description or a CLAUDE.md / developer docs update so it doesn't surprise contributors.

integrationTest source set removed — was this intentional?

The PR removes the entire integrationTest source set and its companion MainTest.kt. The PR description does not mention this. The removed test (src/integration-test/kotlin/.../MainTest.kt) was calling real AWS commands (up, use, install, start, down, clean) without any assertions, which makes it a low-value test, so removing it is arguably fine. However:

1. If there are plans to add real integration tests later, the scaffolding (source set, task, configuration inheritance) should be re-added at that point rather than deleted now.
2. If this is intentional cleanup, the PR description should say so explicitly.

---

Minor

• gradlew / gradlew.bat changes are standard Gradle-generated wrapper diffs — no concerns.
• The spark/build.gradle.kts repositories block removal is correct; repositories are now managed centrally in settings.gradle.
• mavenLocal() being placed before mavenCentral() in settings.gradle is the right order for local SNAPSHOT resolution (cassandra-analytics builds).

---

Summary

The core upgrade is sound. The main actionable item is the junit-platform-launcher configuration (testImplementation vs testRuntimeOnly in the root module). Everything else is either correct or a documentation/intent question worth a quick clarification.

[rustyrazorblade]

@claude still has build failures

[claude]

Claude finished @rustyrazorblade's task in 1m 23s —— View job

---

Diagnosis & Fix

• Check current CI status
• Identify failing job(s)
• Download and analyze logs
• Fix issues and push

Root Cause: Wrong shadow plugin import package

The previous fix changed the import to com.gradleup.shadow.tasks.ShadowJar, but Shadow 9.x still uses the old com.github.jengelman package for its task classes — only the plugin ID changed to com.gradleup.shadow, not the Java class packages.

CI error:

Line 01: import com.gradleup.shadow.tasks.ShadowJar
                     ^ Unresolved reference 'gradleup'.

Line 26: tasks.withType<ShadowJar> {
                        ^ Unresolved reference 'ShadowJar'.
4 errors

Fix Applied

Reverted build.gradle.kts:1 to the correct import:

import com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar

Shadow 9.x renamed the Gradle plugin ID (com.gradleup.shadow) but did not rename the Java task class packages — ShadowJar and other task classes remain under com.github.jengelman.gradle.plugins.shadow.tasks. The earlier review comment suggesting the import should be updated was incorrect.

Committed as de38922 and pushed to the branch.

View job | Branch

[claude]

PR Review: Upgrade Gradle to 9.4.0

Overall this is a clean, well-structured upgrade. The changes follow Gradle 9's recommended patterns and the housekeeping (removing stale integration tests) is welcome. A few things worth discussing:

---

bin/easy-db-lab — Auto-build removal

Concern: The automatic shadowJar installDist step was removed without a clear fallback for developers who run this script directly. If someone runs bin/easy-db-lab without having built the JAR first, they'll get a silent failure or cryptic "file not found" error at the java -jar $JAR line.

Suggestion: Either add a JAR existence check with a helpful message, or document the new expected workflow:

# Optional: add this check before the java invocation
if [ ! -f "$JAR" ]; then
    echo "Error: JAR not found at $JAR. Run './gradlew shadowJar' first." >&2
    exit 1
fi

If bin/dev now handles the build step, it's worth a comment in the script pointing to it.

---

mavenLocal() in settings.gradle

mavenLocal() is correctly placed before mavenCentral() for cassandra-analytics local builds. Worth noting that this ordering means any locally-installed artifact can shadow its published version, which is intentional here but could surprise developers who have stale local builds. A comment near the block would help:

dependencyResolutionManagement {
    repositories {
        mavenLocal() // Required for locally-built cassandra-analytics snapshots
        mavenCentral()
    }

---

Removal of integrationTest source set

The stale MainTest.kt (using init, up, use, install, start, down, clean commands) was correctly removed — those commands no longer exist. The commit message confirms the end-to-end test script is the real integration test now. This is the right call, no concerns here.

---

junit-platform-launcher dependency

Necessary for Gradle 9's JUnit Platform launcher support. Adding it to both the version catalog bundle and spark/common is correct.

---

Wrapper script changes (gradlew, gradlew.bat)

Standard Gradle 9.4-generated content. The -classpath → -jar change, APP_HOME fix using printf '%s\n' "$PWD", and SPDX header addition are all expected from gradle wrapper regeneration. No concerns.

---

Repository consolidation

Moving from allprojects { repositories {} } in build.gradle.kts to dependencyResolutionManagement in settings.gradle is the correct Gradle 9 approach. Gradle 9 emits deprecation warnings for project-level repository declarations in allprojects, so this avoids future churn.

---

Summary: The upgrade itself is solid. The main thing to address before merging is the bin/easy-db-lab UX regression from removing auto-build — either add a helpful error message for missing JAR, or ensure there's documentation/guidance for the new expected workflow.