LSN-0037: Gradle Version Catalog for Dependency Management

Original Problem

Dependency versions were scattered across the project, including hardcoded strings in buildSrc conventions and build.gradle.kts files. This fragmentation made maintenance difficult and prevented a clear overview of external dependencies.

Consolidated Decision

Adopt gradle/libs.versions.toml (Version Catalog) as the single source of truth for all external dependencies and versions in the prometeu-studio repository.

Final Implementation

Version Catalog Definition: Centralized all external libraries in gradle/libs.versions.toml under the [versions] and [libraries] sections.
buildSrc Access: Configured buildSrc to consume the same catalog by using the VersionCatalogsExtension in the gradle.java-common-conventions.gradle.kts file.
Convention Refactoring: Updated Java common conventions to use libs.findLibrary(...).get() for resolving dependencies from the catalog.

Example: Using Catalog in buildSrc (Kotlin DSL)

Since buildSrc is a separate build, the type-safe accessors (like libs.lombok) are not automatically generated in the same way as in the main project modules. We use the following pattern:

val libs = extensions.getByType<VersionCatalogsExtension>().named("libs")

dependencies {
    implementation(libs.findLibrary("lombok").get())
}

Examples and Usage

In standard modules (build.gradle.kts), use the type-safe accessors provided by Gradle:

dependencies {
    implementation(libs.javafx.controls)
}

Common Pitfalls

buildSrc Visibility: Direct access like libs.libraryName might fail in buildSrc if the catalog isn't properly shared or if the accessor isn't generated for the buildSrc context. Using VersionCatalogsExtension is the most robust way to share it.
Naming Consistency: Ensure library aliases in TOML follow a clear pattern (e.g., slf4j-api vs slf4jApi) to keep the build scripts readable.

2.2 KiB Raw Blame History