Gradle-依赖管理

　　几乎所有的基于JVM的软件项目都需要依赖外部类库（通常l以ar形式存在）来重用现有功能。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

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

1.dependencies {
    ccmpile "org.apache.commons:commons-email:1.53.
    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 "ScargoGroup: cango-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 {
    fail0nversionConflict()
}

　　失败对于调试目的很有帮助，特别是建立项目的早期阶段和改变依赖关系时，运行项目的任何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:slt4j-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"
    }
}

　　写在最后：当然，绝大部分情况下是不需要我们去解决版本冲突问题的，因为Gradle的默认解决方案（使用最新）可以解决掉90%以上的冲突问题。剩余不能解决的就可以参照上面的步骤