Gradle提供了足够的工具来导航较大的依赖图并缓解可能导致依赖地狱的情况 . 用户可以选择呈现完整的依赖关系图,也可以确定选择原因和依赖关系的来源. 依赖关系的来源可以是构建脚本中已声明的依赖关系,也可以是图形中的传递性依赖关系及其相应的配置. Gradle通过构建扫描的可视化表示和命令行工具提供了两种功能.

Build scans

如果您不知道什么是构建扫描 ,请确保将其签出!

构建扫描可以将依赖项可视化为可导航的可搜索树. 通过单击图形中的特定依赖项,可以呈现其他上下文信息.

dependency management dependencies report build scan
图1.构建扫描中的依赖树

Listing dependencies in a project

Gradle可以可视化项目中每个可用配置的整个依赖树.

如果您想确定在运行时已解决了哪些依赖关系,则渲染依赖关系树特别有用. 它还为您提供有关该过程中发生的任何依赖项冲突解决方案的信息,并清楚地指示所选版本. 依赖性报告始终包含已声明和可传递的依赖性.

假设您要为使用JGit库执行SCM操作(例如,为发布过程建模)的项目创建任务. 您可以在自定义配置的帮助下声明任何外部工具的依赖关系,这样它就不会污染其他上下文,例如生产源代码的编译类路径.

每个Gradle项目都提供任务dependencies以从命令行呈现所谓的依赖项报告 . 默认情况下,相关性报告呈现所有配置的相关性. 要专注于有关一种配置的信息,请提供可选参数--configuration .

示例1.使用自定义配置声明JGit依赖项
build.gradle
repositories {
    jcenter()
}

configurations {
    scm
}

dependencies {
    scm 'org.eclipse.jgit:org.eclipse.jgit:4.9.2.201712150930-r'
}
build.gradle.kts
repositories {
    jcenter()
}

configurations {
    create("scm")
}

dependencies {
    "scm"("org.eclipse.jgit:org.eclipse.jgit:4.9.2.201712150930-r")
}

Example: Rendering the dependency report for a custom configuration

gradle -q dependencies --configuration scm输出gradle -q dependencies --configuration scm
> gradle -q dependencies --configuration scm

------------------------------------------------------------
Root project
------------------------------------------------------------

scm
\--- org.eclipse.jgit:org.eclipse.jgit:4.9.2.201712150930-r
     +--- com.jcraft:jsch:0.1.54
     +--- com.googlecode.javaewah:JavaEWAH:1.1.6
     +--- org.apache.httpcomponents:httpclient:4.3.6
     |    +--- org.apache.httpcomponents:httpcore:4.3.3
     |    +--- commons-logging:commons-logging:1.1.3
     |    \--- commons-codec:commons-codec:1.6
     \--- org.slf4j:slf4j-api:1.7.2

A web-based, searchable dependency report is available by adding the --scan option.

依赖性报告提供了有关图形中可用依赖性的详细信息. 任何无法解决的依存关系FAILED标记为红色. 图表中可能多次出现的具有相同坐标的依赖项被省略,并用星号表示. 必须进行冲突解决的依赖项会以右箭头字符分隔请求的版本和选定的版本.

Identifying which dependency version was selected and why

大型软件项目不可避免地会通过直接或传递依赖关系来处理越来越多的依赖关系. 依赖关系报告为您提供了依赖关系的原始列表,但没有说明为什么选择它们,或者由哪个依赖关系将它们拉入图形.

让我们看一个具体的例子. 一个项目可以请求相同依赖关系的两个不同版本,无论是直接依赖关系还是传递依赖关系. Gradle应用版本冲突解决方案来确保依赖关系图中仅存在一个版本的依赖关系. 在此示例中,冲突的依赖性由commons-codec:commons-codec .

例子2.声明JGit依赖和一个冲突的依赖
build.gradle
repositories {
    jcenter()
}

configurations {
    scm
}

dependencies {
    scm 'org.eclipse.jgit:org.eclipse.jgit:4.9.2.201712150930-r'
    scm 'commons-codec:commons-codec:1.7'
}
build.gradle.kts
repositories {
    jcenter()
}

configurations {
    create("scm")
}

dependencies {
    "scm"("org.eclipse.jgit:org.eclipse.jgit:4.9.2.201712150930-r")
    "scm"("commons-codec:commons-codec:1.7")
}

如果单击依赖项并选择" Required By"选项卡,则构建扫描中的依赖项树将呈现选择原因(冲突解决)以及依赖项的来源.

dependency management dependency insight report build scan
图2.构建扫描中的依赖关系洞察能力

每个摇篮项目提供任务dependencyInsight呈现在命令行所谓的依赖洞察力报告 . 给定依赖关系图中的依赖关系,您可以识别选择原因并跟踪依赖关系选择的来源. 您可以将依赖关系洞察报告视为给定依赖关系的依赖关系报告的逆表示. 执行任务时,必须提供强制性参数--dependency来指定要检查的依赖项的坐标. 参数--configuration--singlepath是可选的,但有助于过滤输出.

Example: Using the dependency insight report for a given dependency

gradle -q dependencyInsight --dependency commons-codec --configuration scm
> gradle -q dependencyInsight --dependency commons-codec --configuration scm
commons-codec:commons-codec:1.7
   variant "default" [
      org.gradle.status = release (not requested)
   ]
   Selection reasons:
      - By conflict resolution : between versions 1.7 and 1.6

commons-codec:commons-codec:1.7
\--- scm

commons-codec:commons-codec:1.6 -> 1.7
\--- org.apache.httpcomponents:httpclient:4.3.6
     \--- org.eclipse.jgit:org.eclipse.jgit:4.9.2.201712150930-r
          \--- scm

A web-based, searchable dependency report is available by adding the --scan option.

Resolving version conflicts

If the selected version does not match your expectation, Gradle offers a series of tools to help you control transitive dependencies.

Resolving variant selection errors

有时会在变体选择级别上发生选择错误. 请查看专用部分以了解这些错误以及如何解决它们.

Resolving unsafe configuration resolution errors

跨越项目边界时,必须安全地解决配置问题,因为解决配置问题会对Gradle的项目模型产生副作用. Gradle可以管理此安全访问,但是需要以使Gradle能够进行访问的方式来访问配置. 有多种方法可以不安全地解决配置问题,并且Gradle会针对每个不安全的访问产生弃用警告.

例如:

  • 一个项目中的任务直接解决另一个项目中的配置.

  • 任务将另一个项目中的配置指定为输入文件集合.

  • 一个项目的构建脚本在评估期间解析另一个项目中的配置.

如果您的构建具有不安全的访问弃用警告,则需要对其进行修复. 这是这些不良做法的征兆,可能会导致奇怪且不确定的错误.

在大多数情况下,可以通过在另一个项目上创建跨项目的依赖关系来解决此问题. 有关更多信息,请参见用于在项目之间共享输出的文档. 如果您发现无法使用这些技术解决的用例,请通过提交遵循我们的发行准则的GitHub Issue来通知我们.