Goal
Adopt the module script-plugin approach used by the recently modernised Spine
repositories (base-libraries,
core-jvm,
compiler, …) so that each subproject is
configured by plugins { id("module") } (or id("jvm-module")) instead of a large block of
imperative per-project setup in the root build.gradle.kts.
Current state
The root build.gradle.kts is 557 lines, most of it per-project
configuration applied from a subprojects { … } block through hand-rolled Project
extension functions:
applyPlugins() — applies java-library, org.jetbrains.kotlinx.kover,
com.google.protobuf, net.ltgt.errorprone, kotlin, pmd, maven-publish,
pmd-settings, dokka-setup, io.spine.core-jvm, plus IncrementGuard, BomsPlugin,
and license / Javadoc / Checkstyle configuration.
setupJava(), setupKotlin(), setupTestTasks(), defineDependencies(),
applyGeneratedDirectories(), forceConfigurations(), setupPublishing(),
configureTaskDependencies().
This re-implements, by hand, the build contract the organisation now centralises in
convention plugins — so every change to that shared contract has to be re-applied here
manually, and the root script drifts from the other repos.
Target
- Move the per-module setup into the
module / jvm-module script plugin. The repo
already ships buildSrc/src/main/kotlin/module.gradle.kts — the project-owned module
convention plugin (it is the explicit buildSrc/** exception in AGENTS.md), which is
the natural landing spot.
- Each subproject's
build.gradle.kts shrinks to plugins { id("module") } plus its own
dependencies.
- The root
build.gradle.kts keeps only genuinely root-level concerns — aggregation
(KoverConfig, LicenseReporter, PomGenerator), spinePublishing, repositories — and
drops the subprojects { } setup-function machinery.
- Mirror the structure of
base-libraries / core-jvm / compiler.
Notes
- The recent JaCoCo → Kover migration was applied inside
applyPlugins(); the
module / jvm-module plugin already auto-applies Kover, so this refactor absorbs that
change rather than conflicting with it.
- Build-only refactor — no production or test code changes; coverage, publishing, and
report outputs must stay equivalent.
Goal
Adopt the
modulescript-plugin approach used by the recently modernised Spinerepositories (
base-libraries,core-jvm,compiler, …) so that each subproject isconfigured by
plugins { id("module") }(orid("jvm-module")) instead of a large block ofimperative per-project setup in the root
build.gradle.kts.Current state
The root
build.gradle.ktsis 557 lines, most of it per-projectconfiguration applied from a
subprojects { … }block through hand-rolledProjectextension functions:
applyPlugins()— appliesjava-library,org.jetbrains.kotlinx.kover,com.google.protobuf,net.ltgt.errorprone,kotlin,pmd,maven-publish,pmd-settings,dokka-setup,io.spine.core-jvm, plusIncrementGuard,BomsPlugin,and license / Javadoc / Checkstyle configuration.
setupJava(),setupKotlin(),setupTestTasks(),defineDependencies(),applyGeneratedDirectories(),forceConfigurations(),setupPublishing(),configureTaskDependencies().This re-implements, by hand, the build contract the organisation now centralises in
convention plugins — so every change to that shared contract has to be re-applied here
manually, and the root script drifts from the other repos.
Target
module/jvm-modulescript plugin. The repoalready ships
buildSrc/src/main/kotlin/module.gradle.kts— the project-owned moduleconvention plugin (it is the explicit
buildSrc/**exception inAGENTS.md), which isthe natural landing spot.
build.gradle.ktsshrinks toplugins { id("module") }plus its owndependencies.
build.gradle.ktskeeps only genuinely root-level concerns — aggregation(
KoverConfig,LicenseReporter,PomGenerator),spinePublishing, repositories — anddrops the
subprojects { }setup-function machinery.base-libraries/core-jvm/compiler.Notes
applyPlugins(); themodule/jvm-moduleplugin already auto-applies Kover, so this refactor absorbs thatchange rather than conflicting with it.
report outputs must stay equivalent.