在哪里可以找到例如的库版本使用 Gradle 版本目录的 `implement(compose.runtime)`

问题描述 投票:0回答:1

Compose Multiplatform 向导使用 Gradle 版本目录创建了一个项目,这对我来说是新的。 我现在有点了解如何在

libs.versions.toml
中声明依赖项以及如何在
build.gradle.kts
依赖项中引用它们。但是,还存在使用
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)
    }
}

我不明白这些来自哪里(即它是特定的构建功能还是带有特定的插件等),特别是我想知道它们对应的确切库和版本。

此外,除了由于省略了

libs.
而变得更短之外,它们还有其他好处吗?例如,
compose.desktop.currentOs
看起来不太像一个特定的库,而不是某种选择平台相关库的快捷方式。

gradle android-jetpack-compose gradle-kotlin-dsl compose-multiplatform jetbrains-compose
1个回答
0
投票
在这种情况下,

compose
是一种扩展类型。扩展提供了一种类型安全的方式来公开可在任务、插件或 Gradle 构建中的任何地方使用的配置。

compose
扩展的类型为
ComposeExtension
。它由 Compose 插件注册,如here 以及其他扩展一样。

Gradle 中的许多类型都实现了

ExtensionAware
接口,该接口允许扩展类型,如额外属性文档中所述。 Compose 插件正是为
dependencies { }
执行此操作,如此处所示。

Compose 插件提供了多个依赖项作为扩展属性,如here所示。这是否“更好”取决于偏好或意见。我的理解是,Compose 插件作者更喜欢提供或管理 Compose Multiplatform 的依赖项,因为他们在插件中将它们作为扩展属性提供。这使得开发人员能够专注于构建他们的应用程序,而不是试图找出需要什么依赖项。

© www.soinside.com 2019 - 2024. All rights reserved.