https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
v
Can you use version catalogs for BOM imported dependencies?
Of course. A version catalog is just what it says, a catalog. Libraries in it can be declared wihtout (or empty) version like when you do it in the build script directly, so tha the version can come from somewhere else like a BOM
But you should stop using the Spring Dependency Management plugin and instead use the built-in BOM support with 
platform(...)
. It is an obsolete relict from times when Gradle did not have built-in BOM support and even its maintainer strongly recommends not to use it anymore but to use the built-in BOM support instead. By now it does not really provide any added value anymore and does more harm than good.
j
Awesome! I'll give it a try. So if I'm understanding, just declare the BOM within the 
dependencyManagement
section like the other BOMs I'm using. Then, in the library just define the dependencies in the library without the version
v
dependencyManagement
is Maven, not Gradle
Or well, it is Spring Dependency Management plugin also, so no, I said you should not use that
Here an example from a project I currently have open:
Copy code
dependencies {
    implementation(platform(libs.build.kotlinx.serialization.bom))
    implementation(libs.build.kotlinx.serialization.core)
    implementation(libs.build.kotlinx.serialization.json)
}
and in the version catalog
Copy code
[versions]
build-kotlinx-serialization = "1.5.1"

[libraries]
build-kotlinx-serialization-bom = { module = "org.jetbrains.kotlinx:kotlinx-serialization-bom", version.ref = "build-kotlinx-serialization" }
build-kotlinx-serialization-core = { module = "org.jetbrains.kotlinx:kotlinx-serialization-core" }
build-kotlinx-serialization-json = { module = "org.jetbrains.kotlinx:kotlinx-serialization-json" }
j
oh you're saying the bom itself can be defined as a library
v
It can if you like. As I said, the version catalog is just a catalog of coordinates and versions, nothing more, nothing less.
j
very interesting!
the one tricky thing i was running into was libraries that are annotation processors and need to be added at compile time, i.e. lombok
libraries felt a bit verbose at that point, but i do like the concept for sure
v
How you use those coordinates is separate story. Whether you exclude something from them, or request a classifier, or a feature variant through capability, or some attributes, ..... All usage-side, not version-catalog side. And that it is used as BOM just means a specific attribute is requested.
the one tricky thing i was running into was libraries that are annotation processors and need to be added at compile time, i.e. lombok
Besides that I majorly dislike lombok, what should be tricky?
j
lol
v
It's just the same with it, nothing special
Just that you use it for 
annotationProcessor
and 
compileOnly
, not for 
implementation
j
right, i'm saying you're not gaining any conciseness over just defining the dependency
v
version catalog is not about conciseness
j
i.e.:
Copy code
compileOnly lombok.version
annotationProcessor lombok.version

vs. 
compileOnly libs.lombok
annotationProcessor libs.lombok
v
It is about a central place for defining all libraries and versions
j
yeah i understand that now
v
And it is for being able to change versions without invalidating all tasks because the build script changed
j
yep, it's pretty awesome! plus with the bundles you can easily group things up
which is really awesome
also love that intellij is smart about navigating to the different libraries you define, makes navigating really easy
v
👌
Code completion also coming soon iirc
j
Very nice, well cool, I have more to play around with tomorrow at work, then! The only other thing I was going to ask, is the general guidance to use the toml files to manage this? I was putting it in the project root 
settings.gradle
v
Do whatever you like. But if you then only change a version, all build scripts class paths change so all tasks are going to be out-of-date. With the TOML, only where the version is actually used will be out-of-date. My recommendation is, use TOML if you can, and the settings script DSL only if you need it for some reason like calculating something, or extracting the information from some other format you already have or whatever.
Also, the TOML is a simple parseable file, not a turing complete language. So some tools might parse it and operate on the information, while they might not when defined through settings DSL.
j
Great, yeah I didn't have a strong opinion either way, that makes sense. I'll give it a go and see how I like it!
👌 1
m
Go with TOML 😉
👍 1
Open in Slack
PreviousNext
Powered by