Fix dead Compiler and Validation artifact coordinates

[alexander-yevsyukov]

Problem

Four Maven coordinates declared under buildSrc/src/main/kotlin/io/spine/dependency/local/ do not resolve against the Spine Artifact Registry — verified against maven-metadata.xml in both releases and snapshots:

Coordinate	Declared as	Status
io.spine.tools:compiler-cli-api	Compiler.cliApi	never published at any version
io.spine.tools:compiler-fat-cli	Compiler.fatCli	never published at any version
io.spine.tools:validation-model	Validation.model	last published 2.0.0-SNAPSHOT.375
io.spine.tools:validation-configuration	Validation.configModule	last published 2.0.0-SNAPSHOT.375

Root cause

Compiler.kt descends from ProtoData.kt — the two are line-for-line identical around both dead entries. When ProtoData was superseded by the Spine Compiler, the object was copied and the protodata- prefix mechanically swapped for compiler-, but two module renames that had happened inside the compiler repository were never carried over:

• cli-api → params, in SpineEventEngine/compiler@7f3592533d "Rename the cli-api module to params". Compiler.params already declares the surviving artifact, which makes cliApi a duplicate.
• fat-cli → cli-all. cli/build.gradle.kts publishes artifactId = "compiler-cli-all" via the cliFatJar publication. The Compiler's own public API — Artifacts.fatCli() in compiler-gradle-api — already returns compiler-cli-all, so the Compiler disagreed with its own build tooling about the same artifact.

In SpineEventEngine/validation:

• model was consolidated into context, and its remainder renamed to context-tests (4af8c8cc64), which is test-only and absent from the published modules set. Validation.context already declares the surviving artifact.
• configuration was dropped with no successor (e48782ac88 "Remove outdated configuration proto code", c665d06dac "Remove :proto:configuration module"). The newer java-settings module is unrelated, introduced separately in ede1d77f52.

Why this went unnoticed

Compiler.modules feeds ResolutionStrategy.force(...) via Dependency.artifacts. Forcing a coordinate that never appears in a dependency graph is a silent no-op — Gradle emits neither a warning nor a failure.

Changes

• Compiler.cliApi removed, along with its entry in Compiler.modules.
• Compiler.fatCli corrected to compiler-cli-all, with a KDoc note pinning it to the upstream Artifacts.fatCli() — which carries the mirror-image instruction on its own side.
• Validation.model and Validation.configModule removed.

Coordinates only — Compiler.fallbackVersion, fallbackDfVersion, and Validation.version are deliberately untouched.

No migrate entry is needed: migrate distributes buildSrc with cp -R buildSrc .., which overwrites these files wholesale. Its rm -f cleanups exist only for dependency objects removed as entire files (ProtoData.kt, ModelCompiler.kt, McJava.kt); no whole file is removed here.

Open question for review: removal vs. @Deprecated

The two reviewers that examined this disagreed, so it is worth a maintainer's call.

dependency-audit argued for @Deprecated markers, citing Validation.oldRuntime as in-file precedent and the possibility of unseen external consumers.

kotlin-engineer argued for straight removal, and I find its reasoning stronger:

• oldRuntime is the opposite case — it points at a real, published artifact and has a real replacement, so ReplaceWith("runtime") is meaningful. configModule has no successor at all, so there is no expression to put in ReplaceWith.
• Deprecation does not prevent the break, it relocates it. These artifacts do not exist, so a consumer still fails — but a deprecated-yet-resolvable constant turns a compile-time Unresolved reference: cliApi, which names the exact call site, into a later Could not find io.spine.tools:validation-model:… that reads like an infrastructure outage.
• Deprecate-then-remove buys source/binary compatibility for consumers who cannot recompile. buildSrc is compiled from source in every consumer, and config is a pinned submodule pulled explicitly — nobody is upgraded silently.

A grep across every locally checked-out SDK repository found zero references to any of the four declarations. Happy to switch to deprecation markers if you prefer.

Verification

• ./gradlew detekt — BUILD SUCCESSFUL; :buildSrc:compileKotlin clean. (This repo registers no build, check, or dokkaGenerate task — its root project applies no base/java/Dokka plugin — so detekt + compileKotlin is the applicable surface.)
• Swept every remaining coordinate in both objects against the registry at its declared version — all resolve, including compiler-cli-all:2.0.0-SNAPSHOT.064.
• Reviewers: spine-code-review APPROVE, kotlin-engineer APPROVE, review-docs APPROVE, dependency-audit APPROVE WITH CHANGES (the deprecation question above). No Must-fix findings.

Follow-ups, not addressed here

• kotlin-engineer suggests extracting fatCliModule so the artifact id is named once, matching the jvm / jvmModule convention.
• The object-wide @Suppress("unused") on both objects is what let these dead members survive; narrowing it would surface the next one.
• Validation declares no java-settings, though io.spine.tools:validation-java-settings is published.

🤖 Generated with Claude Code