gradleandroid-jetpack-composegradle-kotlin-dslcompose-multiplatformjetbrains-compose

Where to find the library version of e.g. `implementation(compose.runtime)` using Gradle version catalog


The Compose Multiplatform wizard created a project using the Gradle version catalog, which is new to me. I kind of understand now how to declare dependencies in libs.versions.toml and how to reference them in the build.gradle.kts dependencies. However, there are also dependencies being declared using compose.*:

sourceSets {
    val desktopMain by getting

    androidMain.dependencies {
        implementation(libs.androidx.activity.compose)
        implementation(libs.androidx.material)
    }
    commonMain.dependencies {
        implementation(compose.runtime)
        implementation(compose.foundation)
        implementation(compose.material3)
        implementation(compose.ui)
        implementation(compose.components.resources)
        implementation(libs.vinceglb.filekit.core)
    }
    desktopMain.dependencies {
        implementation(compose.desktop.currentOs)
        implementation(libs.kotlinx.coroutines.swing)
    }
}

I don't undestand where these come from (i.e. is it a specific build feature or does it come with a specific plugin etc.) and expesially I'd like to know which exact libraries and versions they correspond to.

Also, do they provide any benefits other than being shorter due to the omitted libs.? For example compose.desktop.currentOs doesn't quite seem like a specific library rather than some sort of a shortcut for choosing a platform dependent library.


Solution

  • compose in this context is an extension type. Extensions provide a type-safe way to expose configuration that can be used in tasks, plugins, or essentially anywhere within the Gradle build.

    The compose extension is of type ComposeExtension. It is registered by the Compose plugin as seen here along with other extensions.

    A lot of types within Gradle implement the ExtensionAware interface which allows types to be extended as explained in the documentation for extra properties. The Compose plugin does exactly this for dependencies { } as seen here.

    The Compose plugins provides several dependencies as extension properties as well as seen here. Whether or not this is "better" is a matter of preference or opinion. My understanding is that the Compose plugin authors prefer to provide or manage the dependencies for the Compose Multiplatform since they provide them right in the plugin as extension properties. This allows developers to focus on building their applications rather than trying to figure out what dependency is needed.