is it possible to define variables in `gradle.properties` (like coroutinesVersion=1.6.1 or kotlinVer...

# gradle

[janvladimirmostert]

is it possible to define variables in gradle.properties (like coroutinesVersion=1.6.1 or kotlinVersion=1.6.20) and then inside build.gradle.kts access it somehow?

plugins {
   kotlin("multiplatform").version(kotlinVersion).apply(false)

val commonMain by getting {
   dependencies {
      api("org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutinesVersion")

Alternatively, what is the consensus on using version catalogues (define a catalogue in the root and then keep all the module depenendency versions in sync like this)
https://docs.gradle.org/current/userguide/platforms.html

[janvladimirmostert]

this actually works really well!

dependencyResolutionManagement {
   versionCatalogs {
      create("libs") {
         library("kotlinx-coroutines", "org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.1")
      }
   }
}

implementation(libs.kotlinx.coroutines)

[Matthew Gast]

For reference, you can define variables in gradle.properties and access via the extra delegate.

For example, you could access coroutinesVersion by defining val coroutinesVersion: String by project.

[Vampire]

But you really shouldn't for versions, now that the version catalogs feature is there.
You can either define it via DSL like you showed, or in a TOML file.

[janvladimirmostert]

the version catalogue seems to cover all my use-cases
had to upgrade Gradle to use it, but that's fine, would have had to upgrade at some point anyways

[Matthew Gast]

I'd be careful with relying on that too much. I have used it in the past, but it can be super finicky as Gradle sometimes refuses to compile the stubs properly (and thus causes builds to fail). It's also marked as incubating, so there's a small chance it may still change between now and when it becomes stable.

That said, there are a few alternatives to gradle.properties and dependency catalogs, including using Gradle's platform feature (which does not work with KMPP AFAIK) or defining your dependencies in buildSrc. Each have their own pros and cons, so it's up to you to decide which approach you want to take.

[Vampire]

It is not incubating unless you use an outdated Gradle version

[Vampire]

Version catalogs are promoted to stable already and I never had problems with them, even while they were a feature preview only

[Matthew Gast]

It's showing up as incubating for me in 7.4.2. Although it could be weirdness with IDEA.

[Vampire]

They were promoted to stable with 7.4.
There was a bug that it was still reported as incubating that was fixed with 7.4.1.
Maybe you look at an incubating message for project accessors?

[Vampire]

Can you show a log or screenshot where it is shown as incubating?

[Matthew Gast]

message has been deleted

[Vampire]

Hm, interesting that intellij does not warn me about its incubating status then.
But nevertheless, as your message says, the dependencyResolutionManagement block is incubating.
Version catalogs themselves are already promoted to stable.

[Vampire]

So the configuration within versionCatalogs should be stable already, or to play super safe, just use the TOML instead.

[janvladimirmostert]

I'm using it for Multiplatform

I'm also getting that warning using Gradle 7.4.2 although it comes and go