Need help with convention plugins and version-catalog

Help/Discuss
1

I’m using gradle 8.13, and I want to achieve a setup like this (version catalog module hasn’t been added yet, but I use the versions from gradle/libs.versions.toml in the convention plugin:

  1. Build repo with these modules, each published separately:
    • Build-logic with convention plugins
    • Version catalog with a single publication that publishes the catalog from gradle/libs.versions.toml
    • Codegen (gradle build file with codegen config for spring boot)
  2. Shared libraries monorepo, observability, datasource, etc.
  3. Service repositories, one per microservice

The challenge is with the build-repo.
The convention plugins are plain build.gradle.kts files that aggregate some build config for all other repos.
I want to share the version catalog among all repos, such that the build repo uses it, and publishes it, and the the convention plugins use that as well.

So far this works for the conventions plugins
I put this is the build.gradle.kts in the root of the convention plugins module:

dependencies {
   implementation(files(libs.javaClass.superclass.protectionDomain.codeSource.location))
}

Then I use it in the convention plugin this way:

val libs = the<LibrariesForLibs>()

dependencies {
    implementation(platform(libs.kotlinBom))
}

However, when I try to use the generated plugin in a service repo like this :

plugins {
    id("company.kt-spring-conventions") version "0.2.0-SNAPSHOT"
}

I get this error:

> Failed to apply plugin 'company.kt-conventions'.
   > Type org.gradle.accessors.dm.LibrariesForLibs not present

I’d like to avoid duplication version declarations, so my question is what is the recommended way to achieve this?
I thought about trying to first publish the version-catalog, and when I have an artifact I’d import that in the conventions, but I’m still unsure regarding how the consuming project would “see” it.

The only documentation I find is about monorepos when there is a buildSrc folder where conventions go, and has a version catalog usage samples, but I can’t find anything about the use-case I described.

Thanks.

2

An important part of my hack-around that you use is, that on the plugin project and on the consuming project the exact same version catalog has to be present.

Using libs.kotlinBom in the precompiled script plugin is effectively just syntactic sugar over doing

the<VersionCatalogsExtension>()
    .find("libs")
    .flatMap { it.findLibrary("kotlinBom") }
    .get()

which also requires that the consuming project has a version catalog called libs with an entry named kotlinBom.

3

Thanks,

So to make sure I understand correctly - If I had first created the version catalog, regardless of wether the *.toml file is in the same source repository as the conventions plugin, and use that for both the convention and the consuming project, It’ll all work as expected?

4

If I understood you correctly, yes