Is there a simpler way to specify dependency versions in a central location in a type-safe and auto-...

# gradle

[Marc Knaup]

Is there a simpler way to specify dependency versions in a central location in a type-safe and auto-complete friendly way other than using buildSrc? So that it can be used across all build scripts.

https://github.com/fluidsonic/raptor/blob/master/buildSrc/sources/Versions.kt

[Big Chungus]

Have you had a look at gradle catalogs?

[Big Chungus]

There's also refreshVersions

[Marc Knaup]

Interesting upcoming feature. I’ll check that out once Gradle 7 is released 🙂

Thanks for the info

[Big Chungus]

There's also this being built that aims to super-power gradle catalogs

[Marc Knaup]

That’s weird and doesn’t seem to be useful to me 🤔

[Marc Knaup]

There’s also refreshVersions

I definitely don’t want to use properties files.
If I can write it in Kotlin easily, why use another file format 🙂

[Big Chungus]

Fair enough. It's a bit different to what you're looking for as it is basically giving you the versions with option to override if necessary. The usage is then type-save for the artifacts themselves.

[Big Chungus]

Anyways, not pushing anything to you here, just listing all the options I'm aware of 🙂

[Javier]

Personally I prefer the toml files for Gradle 7.0 catalogs over the kotlin apis

[Javier]

Both generates the same accessors, but toml file is more readable IMO

[Marc Knaup]

Yeah. Projects are full of Kotlin, Shell, Properties, HTML and other file formats. I love to keep things simple, and that includes reducing the amount of languages needed.

buildSrc is already quite simple but it’s an additional module with its own Gradle setup.

[Javier]

Using deps in buildSrc can break some caches

[Javier]

like the new configuration cache

[Marc Knaup]

How could it?

[Marc Knaup]

For the build scripts it’s the same result.
Only difference is that there’s another module to build.

[Big Chungus]

The reason why I personally use refreshVersions is that it even manages that versions.properties file form me. When I'm ready to upgrade, I can just run ./gradlew refreshVersion and the plugin will list out all the new available versions to me. Then it's just a matter of choosing what I'm bumping

[Javier]

Really take a look to the toml files, they are really simple to learn

[Javier]

probably easier than learning the kotlin apis

[Marc Knaup]

@Big Chungus I see. I still use gradle-versions-plugin for now. Bit more manual though.

[Marc Knaup]

@Javier I’ll check out Gradle Catalogs once Gradle 7 is released.

[Big Chungus]

Give it a try, it's quite easy to setup and revert if you don't like it

[Javier]

[versions]
retrofit = "..."

[libraries]
square-retrofit = { group = "...", name = "...", version.ref = "retrofit" }

implementation(libs.square.retrofit)

[Javier]

The rc should be soon

[Marc Knaup]

{ group = "...", name = "...", version.ref = "retrofit" }
no short syntax?

[Javier]

yes, I think group + name can be replaced with module

[Javier]

there are more, but I don't remember them

[nuhkoca]

@javier really seems interesting, does this support autocomplete in kts? And how to deal with version updates?

[Javier]

Accessors has autocomplete, what do you mean with version updates?

[nuhkoca]

Meant how do I know when there is a newer version of a dependency?

[Javier]

ben manes plugin for example. Dependabot doesn't support buildSrc approach, but I think it will support Version Catalog because it will be the standard

[nuhkoca]

Thank you, that's good to know because I actually use ben manes plugin, too :)

Congrats for your work again! I am looking forward to trying it out!

[Javier]

Well, I am not the author of that feature, it is created by the Gradle team :)

[Javier]

My lib is just a few catalogs using that feature

[nuhkoca]

Yeah I congratulated you for your own work :)

[Javier]

Thank you :)