Allow to share dependency versions

[igorwojda]

This is improvement for incubated version catalog feature of Gradle 7M1

Expected Behavior

Allow to define dependency version, so it can be easily shared between

• versions catalogs eg. one catalog for prod and another one for test dependences (practical example: kotlin coroutines have different dependencies for prod and testing with the same lib version)
• versions catalogs and gradle plugin versions (practical example: kotlin-reflect and JetPack Navigation both require gradle plugin and dependency with the same version):

// Case 1 - Kotlin (want to share version between dependency and Gradle plugin)
//Gradle plugin
org.jetbrains.kotlin:kotlin-gradle-plugin:1.4.30

//Lib dependency
org.jetbrains.kotlin:kotlin-stdlib:1.4.30 // I know now this cna be optional
org.jetbrains.kotlin:kotlin-reflect:1.4.30 // Can't be optional


// Case 2 - Navigation (want to share version between dependency and Gradle plugin)
//Gradle plugin
androidx.navigation:navigation-safe-args-gradle-plugin:2.3.3

//Lib dependency
"androidx.navigation:navigation-fragment-ktx:2.3.3"
"androidx.navigation:navigation-dynamic-features-fragment:2.3.3"
"androidx.navigation:navigation-ui-ktx:2.3.3"

// Case 3 - Coroutines (need to share version between implementation and test implementation)
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.9")
testImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:1.3.9")

Current Behavior

Dependency version defined in version catalog can only be shared in context of version catalog

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            version("kotlin", "1.4.30")
            alias("kotlin").to("org.jetbrains.kotlin", "kotlin-stdlib").versionRef("kotlin")
        }
    }
}

Context

Goals here are:

1. Have a single place in te project (file or folder) to define all of the dependencies for the project this includes all library dependencies and Gradle plugins
2. Define dependency version for given tool only once, especially in the case where Gradle plugin and library are sharing version - this way we don’t have to remember about updating the same dependency in multiple places (edited)

More:
https://gradle-community.slack.com/archives/CAD95CR62/p1612804019033000

[igorwojda]

Possible solutions:

pluginManagement {
    val kotlinVersion = "1.4.30"
    plugins {
        kotlin("jvm") version kotlinVersion
    }
    // this must be inside the pluginManagement block as it is
    // evaluated first and standalone to also be able to work for
    // settings plugins, so it could not use a variable defined outside the block
    dependencyResolutionManagement {
        versionCatalogs {
            create("libs") {
                version("kotlin", kotlinVersion)
                alias("kotlin").to("org.jetbrains.kotlin", "kotlin-stdlib").versionRef("kotlin")
            }
        }
    }
}

or

pluginManagement {
    val kotlinVersion by settings.extra("1.4.30")
    plugins {
        kotlin("jvm") version kotlinVersion
    }
}
val kotlinVersion: String by extra
dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            version("kotlin", kotlinVersion)
            alias("kotlin").to("org.jetbrains.kotlin", "kotlin-stdlib").versionRef("kotlin")
        }
    }
}

[Vampire]

Most of what you are asking for is already possible.
If you don't want to declare an alias for a dependency in the catalog for whatever reason, there is libs.versions.kotlin available in your build script to use already.

The actually missing thing here that I just was about to create an issue about before I have seen you created this with my work-around is, that you can (re-)use a version declaration from a catalog for plugin versions.

In the TOML file it is not possible at all to re-use a declared version for plugin versions.

In a programmatically declared version catalog you can use either of the two code snippets from me that Igor quoted, which is not all too nice though.

[ljacomet]

The version catalog feature will be released in Gradle 7.0 without support for plugins, see #16078.
Closing this as not-fixed. Might be picked up if we decide on a way to integrate plugin versions with version catalogs in a satisfying way.