This message was deleted.

e.g. the kotest bom specifies

io.kotest:kotest-framework-api

and

io.kotest:kotest-assertions-shared

amongst others. In

build.gradle.kts

it would be nice to able to declare this:

dependencies {
  testImplementation(platform(libs.kotest.bom))

  testImplementation(libs.kotest.runner.junit5)
  testImplementation(libs.kotest.framework.api)
  testImplementation(libs.kotest.assertions.shared)
}

with this `libs.versions.toml`:

[versions]
kotest = "5.7.2"

[libraries]
kotest-bom = { module = "io.kotest:kotest-bom", version.ref = "kotest" }

Instead I have to have this `libs.versions.toml`:

[versions]
kotest = "5.7.2"

[libraries]
kotest-bom = { module = "io.kotest:kotest-bom", version.ref = "kotest" }

kotest-runner-junit5 = { module = "io.kotest:kotest-runner-junit5" }
kotest-framework-api = { module = "io.kotest:kotest-framework-api" }
kotest-assertions-shared = { module = "io.kotest:kotest-assertions-shared" }

which feels otiose, when the

kotest-bom

already declares those modules.

Except that: • Gradle cannot know upfront how kotest-bom will be used (a platform or something else) ; it would also have to resolve the BOM (from which repository?) to be able to generate the accessors. • the naming convention you're expecting might be different from the one someone else expects • generating such accessors might cause conflicts with others you may have in your TOML file • platforms declare dependency constraints that apply to transitive deps, so technically you might not even directly add a dependency whose version is declared in the BOM • what if you declare the BOM with a dynamic or changing version, and the declared constraints change between versions?

Fair enough; perhaps it would make more sense as a plugin (or an IDE helper?) that could expand them into the TOML for you

Sure a settings plugin could very well add libraries to the catalog using the version catalog builder API (it would have to somehow resolve the BOM and parse it though)

I suggest you look at what we do in the

micronaut-build

plugins. We intensively use catalogs, in addition with conventions to determine what needs to be exported in a BOM. We have tools to inline catalogs into other catalogs, typically.