当前位置: 代码迷 >> 综合 >> 「Gradle Tips 系列」如何查看模块的所有依赖
  详细解决方案

「Gradle Tips 系列」如何查看模块的所有依赖

热度:129   发布时间:2023-10-20 03:42:59.0

前言

有时,我们需要查看某个模块所有的依赖(Dependencies),或者是在 CI 构建时,检测是否有依赖变更。

方法

方法一:./gradlew :app:dependencies

在项目根目录下,执行命令:

./gradlew :app:dependencies

注意:请将上述命令中的 app 替换成想查询依赖的那个模块名

输出示例:

Configuration on demand is an incubating feature.
Type-safe project accessors is an incubating feature.
> Task :buildSrc:compileKotlin UP-TO-DATE
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:pluginDescriptors UP-TO-DATE
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes UP-TO-DATE
> Task :buildSrc:inspectClassesForKotlinIC UP-TO-DATE
> Task :buildSrc:jar UP-TO-DATE
> Task :buildSrc:assemble UP-TO-DATE
> Task :buildSrc:compileTestKotlin NO-SOURCE
> Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:validatePlugins UP-TO-DATE
> Task :buildSrc:check UP-TO-DATE
> Task :buildSrc:build UP-TO-DATE> Task :app:dependencies------------------------------------------------------------
Project ':app'
------------------------------------------------------------_internal-unified-test-platform-android-device-provider-ddmlib - A configuration to resolve the Unified Test Platform dependencies.
\--- com.android.tools.utp:android-device-provider-ddmlib:30.1.2+--- com.android.tools:common:30.1.2|    +--- com.android.tools:annotations:30.1.2|    \--- com.google.guava:guava:30.1-jre|         +--- com.google.guava:failureaccess:1.0.1|         +--- com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava|         +--- com.google.code.findbugs:jsr305:3.0.2|         +--- org.checkerframework:checker-qual:3.5.0|         +--- com.google.errorprone:error_prone_annotations:2.3.4|         \--- com.google.j2objc:j2objc-annotations:1.3+--- com.android.tools.ddms:ddmlib:30.1.2|    +--- com.android.tools:common:30.1.2 (*)|    +--- net.sf.kxml:kxml2:2.3.0|    \--- com.google.protobuf:protobuf-java:3.10.0+--- com.google.protobuf:protobuf-java:3.10.0+--- com.android.tools.utp:android-device-provider-ddmlib-proto:30.1.2|    \--- com.google.protobuf:protobuf-java:3.10.0+--- org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.8|    +--- org.jetbrains.kotlin:kotlin-stdlib:1.3.71|    |    +--- org.jetbrains.kotlin:kotlin-stdlib-common:1.3.71|    |    \--- org.jetbrains:annotations:13.0|    \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.3.71\--- com.google.testing.platform:android-device-provider-local:0.0.8-alpha07
# 以下省略

方法二:./gradlew :app:androidDependencies「仅 Android」

这个方法仅对 Android 项目生效:

./gradlew :app:androidDependencies

输出示例:

Configuration on demand is an incubating feature.
Type-safe project accessors is an incubating feature.
> Task :buildSrc:compileKotlin UP-TO-DATE
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:pluginDescriptors UP-TO-DATE
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes UP-TO-DATE
> Task :buildSrc:inspectClassesForKotlinIC UP-TO-DATE
> Task :buildSrc:jar UP-TO-DATE
> Task :buildSrc:assemble UP-TO-DATE
> Task :buildSrc:compileTestKotlin NO-SOURCE
> Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:validatePlugins UP-TO-DATE
> Task :buildSrc:check UP-TO-DATE
> Task :buildSrc:build UP-TO-DATE> Task :app:androidDependencies
debug
debugCompileClasspath - Dependencies for compilation
+--- /Users/lee/code/github/LibChecker/app/ohos/ohos-2.1.1.21.jar
+--- com.github.CymChad:BaseRecyclerViewAdapterHelper:3.0.7@aar
+--- androidx.databinding:databinding-adapters:4.2.2@aar
+--- androidx.databinding:databinding-runtime:4.2.2@aar
+--- androidx.databinding:viewbinding:7.1.2@aar
+--- :hidden-api (variant: debug)
+--- org.jetbrains.kotlin:kotlin-parcelize-runtime:1.6.20@jar
+--- androidx.preference:preference-ktx:1.2.0@aar
+--- androidx.preference:preference:1.2.0@aar
+--- androidx.fragment:fragment-ktx:1.4.1@aar
+--- androidx.activity:activity-ktx:1.4.0@aar
+--- com.github.zhaobozhen:LibChecker-Rules-Bundle:21.3@aar
+--- com.drakeet.about:about:2.5.0@aar
+--- dev.rikka.rikkax.material:material:1.6.6@aar
+--- com.google.android.material:material:1.5.0@aar
+--- androidx.viewpager2:viewpager2:1.1.0-alpha01@aar
+--- dev.rikka.rikkax.appcompat:appcompat:1.4.1@aar
+--- androidx.fragment:fragment:1.4.1@aar
+--- androidx.fragment:fragment:1.4.1@aar
+--- androidx.core:core-ktx:1.7.0@aar
+--- androidx.browser:browser:1.4.0@aar
+--- com.drakeet.multitype:multitype:4.3.0@aar
+--- androidx.recyclerview:recyclerview:1.2.1@aar
+--- androidx.recyclerview:recyclerview:1.2.1@aar
+--- androidx.activity:activity:1.4.0@aar
+--- androidx.coordinatorlayout:coordinatorlayout:1.1.0@aar
+--- androidx.drawerlayout:drawerlayout:1.1.1@aar
# 以下省略

笔者推荐在安卓项目中,优先使用第二种方法

Q&A

Compile Classpath vs Runtime Classpath

注意到,在 ./gradlew :app:androidDependencies 输出中,出现了 debugCompileClasspathdebugRuntimeClasspath,前缀 debug 猜测是指编译类型,那它们的后缀含义上有什么区别呢?

以下面的例子来理解。
假设现在一个 Gradle 项目有一个模块 app,在它的 build.gradle 中声明了它对模块 B 的依赖。并且模块 B 实际上依赖了模块 C。那么:

  • 模块 C 出现在模块 app 和模块 B 的 Runtime Classpath 中。因为运行时需要它。
  • 仅模块 B 出现在模块 app 的 Compile Classpath 中,因为我们需要调用模块 B 的接口实现模块 app 的功能。

根据上述信息可以总结出:

模块名 模块 app 模块 B 模块 C
Compile Classpath B C /
Runtime Classpath BC C /
  相关解决方案