Hey — publishing a version catalog with the `versi...
# community-support
h
Hey — publishing a version catalog with the
version-catalog
plugin, using
.withoutVersion()
on most libraries and only
versionRef
on a BOM alias. Minimal repro:
Copy code
// build.gradle.kts
plugins {
    `version-catalog`
}
catalog {
    versionCatalog {
        val versionAlias = version("mylib", "1.0.0")
        library("bom", "com.example", "mylib-bom").versionRef(versionAlias)
        library("core", "com.example", "mylib-core").withoutVersion()
    }
}
Generated TOML:
Copy code
[versions]
mylib = "1.0.0"

[libraries]
bom = { group = "com.example", name = "mylib-bom", version.ref = "mylib" }
core = { group = "com.example", name = "mylib-core", version = "" }
If a consumer forgets to apply the BOM as a platform:
Copy code
dependencies {     
   implementation(platform(libs.mylib.bom))
   implementation(libs.mylib.core) // no platform applied
}
...resolution fails with
Could not find com.example:mylib-core:.
— which makes sense once you know the empty version is intentional, but the error message doesn't hint at the cause at all. A couple questions: 1. Is there a way to make Gradle emit a clearer error here — something that mentions the missing platform/BOM rather than just a blank version? 2. Is
.withoutVersion()
+ BOM the recommended pattern for a multi-module library's catalog, or is there a more idiomatic way to enforce "must be used with platform X" at the catalog level? Trying to figure out if I should adopt this for my own multi-module project's catalog or just keep
versionRef
on every library instead.
v
Is there a way to make Gradle emit a clearer error here — something that mentions the missing platform/BOM rather than just a blank version?
Surely not, how should Gradle know whether the version should come from the same dependency added transitively, from a version constraint you add, from a bom you apply, in the original definition directly, .... The only thing Gradle can know is, that no version is defined in any of the supported ways and that is what it complains about.
is there a more idiomatic way to enforce "must be used with platform X" at the catalog level?
You cannot enforce anything with a catalog, it is just a catalog, just a collection of coordinates and versions. You cannot even say in the catalog that something should be used as a platform dependency, as you could also use it different ways. I usually use normal versionRef for the direct dependencies and use a platform to control / upgrade transitive dependencies in a multi-project build, or just version constraints in a single-project build.