gradle-依赖管理

阅读更多

   

依赖管理

       几乎所有的基于JVM的软件项目都需要依赖外部类库（通常以jar形式存在）来重用现有功能。jar文件规范不要求你指定类库版本。然而，将版本号添加到jar文件上来标识一个特定的发布版本(比如:spring-context-3.1.3.RELEASE.jar)是常见的做法。随着项目由小变大，项目所依赖的模块和第三方类库会越来越多。组织和管理好jar文件显得至关重要。

由于Java语言并没提供依赖管理的工具，所以你的团队需要自己开发一套存储和检索依赖的想法。你可能会采取以下几种常见的方法：

• 手动复制JAR文件到目标机器，这是最原始的很容易出错的方法。

• 使用一个共享的存储介质来存储JAR文件(比如共享的网盘)，你可以加载网络硬盘或者通过FTP检索二进制文件。这种方法需要开发者事先建立好与仓库的连接，手动添加新的依赖到仓库中.

• 把依赖的JAR文件同源代码都添加到版本控制系统中。这种方法不需要任何额外的步骤，你的同伴在拷贝仓库的时候就能检索依赖的改变。另一方面，这些JAR文件占用了不必要的空间，当你的项目存在相互之间依赖的时候你需要频繁的check-in的检查源代码是否发生了改变。

 尽管上面的方法都能用，但是这距离理想的解决方案差远了，因为他们没有提供一个标准化的方法来命名和管理JAR文件。至少你得需要开发库的准确版本和它依赖的库(传递依赖)

使用自动化的依赖管理

声明依赖

依赖属性

当依赖管理器从仓库中查找依赖时，需要通过属性的结合来定位，最少需要提供一个name。

• group： 这个属性用来标识一个组织、公司或者项目，可以用点号分隔，Hibernate的group是org.hibernate。
• name： name属性唯一的描述了这个依赖，hibernate的核心库名称是hibernate-core。
• version： 一个库可以有很多个版本，通常会包含一个主版本号和次版本号，比如Hibernate核心库3.6.3-Final。
• classifier： 有时候需要另外一个属性来进一步的说明，比如说明运行时的环境，Hibernate核心库没有提供classifier。

你可以使用下面的语法在项目中声明依赖

dependencies {
    compile 'org.apache.commons:commons-email:1.5'
    compile group: 'org.hibernate', name: 'hibernate-core', version: '5.4.2.Final'
}

       首先声明要给哪个配置添加依赖，然后添加依赖列表，你可以用map的形式来注明，你也可以直接用冒号来分隔属性，比如这样的：

动态指定版本

        如果你想使用一个依赖的最新版本，你可以使用latest.integration，比如声明 Cargo Ant tasks的最新版本，你可以这样写org.codehaus .cargo:cargo-ant:latest-integration，你也可以用一个+号来动态的声明：cargo 'org.codehaus.cargo:cargo-ant:1.+'

        如果你项目中依赖比较多，你把一些共同的依赖属性定义成外部属性可以简化build脚本。

//声明外部属性
ext.cargoGroup = 'org.codehaus.cargo'
ext.cargoVersion = '1.3.1'
dependencies {
	//使用映射声明依赖
	compile group: cargoGroup, name: 'cargo-core-uberjar',version: cargoVersion
	//用快捷方式来声明，引用了前面定义的外部属性
	cargo "$cargoGroup:cargo-ant:$cargoVersion"
}

 配置仓库

repositories {
	mavenCentral()
}

 常用仓库

repositories {
        mavenLocal()//添加本地长裤
        maven {//自定义仓库，私服等
           name 'Custom Maven Repository',
           url 'http://repository.forge.cloudbees.com/release/')
        }
        mavenCentral()//maven中央仓库
        jcenter()//jcenter仓库
}

解决依赖问题

       版本冲突是一个棘手的问题。如果你的项目有很多依赖，而且你选择自动解决传递性依赖，那么版本冲突几乎是不可避免的。Gradle解决版本冲突的默认策略是选择最新的依赖版本（绝大部分情况下可以解决依赖冲突问题）。依赖报告是最有用的工具，它可以帮助选择所需要依赖的版本。

检查依赖报告

当你运行dependencies任务时，这个依赖树会打印出来，依赖树显示了你build脚本声明的顶级依赖和它们的传递依赖

仔细观察你会发现有些传递依赖标注了*号，表示这个依赖被忽略了，这是因为其他顶级依赖中也依赖了这个传递的依赖，Gradle会自动分析下载最合适的依赖。

应对版本冲突

       Gradle不会自动通知你项目遇到了版本冲突问题。必须不断的运行依赖报告以找出冲突并不是一个实际的解决方法。你可以更改默认的解决策略，当遇到版本冲突问题是让构建失败：

 

//所有依赖
configurations.all {
  resolutionStrategy {
    failOnVersionConflict()
  }
}

//or 指定依赖
configurations.hibernate-core.resolutionStrategy {
    failOnVersionConflict()
}

      失败对于调试目的很有帮助，特别是建立项目的早期阶段和改变依赖关系时，运行项目的任何task都会显示版本冲突信息：

Conflict(s) found for the following module(s):
- org.slf4j:slf4j-api between versions 1.7.26 and 1.7.25
Run with:
--scan or
:dependencyInsight --configuration compileClasspath --dependency org.slf4j:slf4j-api
to get more insight on how to solve the conflict.

排除传递依赖

        Gradle允许你完全控制传递依赖，你可以选择排除全部的传递依赖也可以排除指定的依赖，假设你不想使用UberJar传递的xml-api的版本而想声明一个不同版本，你可以使用exclude方法来排除它

compile ('ch.qos.logback:logback-classic:1.2.3'){
//排除传递依赖 exclude
    exclude group: 'org.slf4j', module: 'slf4j-api'
    //transitive = false;//全部排除
}

       exclude属性值和正常的依赖声明不太一样，你只需要声明group和(或)module，Gradle不允许你只排除指定版本的依赖。

       有时候仓库中找不到项目依赖的传递依赖，这会导致构建失败，Gradle允许你使用transitive属性来排除所有的传递依赖：

dependencies {
    implementation('com.google.guava:guava:23.0') {
        transitive = false
    }
}

 项目可以决定完全禁用可传递依赖项（全部排除）

configurations.all {
    transitive = false
}

 强制指定一个版本

configurations.cargo.resolutionStrategy {
    force 'org.slf4j:slf4j-api:1.7.26'//强制性的指定一个版本
}

 或

configurations.all {
  resolutionStrategy {
    force 'org.slf4j:slf4j-api:1.7.26'
  }
}