几乎所有基于JVM的软件项目都需要外部的类库来重用现有的功能代码，自动化依赖管理可以明确依赖的版本，能解决传递性依赖带来的版本冲突问题
依赖管理关键点
1.工作坐标（jar包标志）
group： 指明jar包所在的分组
name：指明jar包的名称
version： 指明jar包的版本
在dependencies中指明依赖的jar包：
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.12'
}
2.仓库（jar包的存放位置）
公共仓库(中央仓库)： mavenCentral/jecenter
Gradle没有自己的中央仓库，可配置使用Maven的中央仓库mavenCenter/jcenter
repositories {
mavenCentral()
jcenter()
}
私有仓库： mavenLocal
配置从本地maven仓库中获取依赖的jar包，不远程加载jar包，使用mavenLocal，需要本地有maven的环境
repositories {
mavenLocal()
}
自定义maven仓库
自定义仓库来源，一般指向公司的Maven私服（普遍做法）
repositories {
maven{
url "私服地址"
}
}
文件仓库(用的很少)
本地机器上的文件路径，一般不使用，没有太大的意义，因为构建工具的目的就是去除本机的影响，可以在任何地方共用一份仓库数据，根本机关联上了就没有太大意义了，特殊情况除外
配置多个仓库的执行顺序
repositories {
mavenCentral()
mavenLocal()
maven {
url "私服地址"
}
}
配置多个仓库时，按照配置的顺利来查找，找到则返回，找不到则继续往下找，例如上面的代码中，会先查找mavenCentral仓，如果没找到则继续从mavenLocal中找，依次类推，直到找到为止
依赖传递性
比如：A依赖B，如果C依赖A，那么C依赖B
就是因为依赖的传递性，所以才会出现版本的冲突问题，以下通过一张图来了解Gradle的自动化依赖管理流程
gradle工具根据*.gradle配置文件从远程仓库下载所需要的jar包并保存的本地仓库，如果同一个jar包经常使用，则会被存入到依赖缓存中
依赖阶段配置
在build.gradle中的dependencies中配置依赖
- 源码依赖：
compile： 配置依赖的jar,测试代码编译和运行以及源码运行一定存在
runtime：配置依赖的jar，只有源码运行和测试运行存在 - 测试依赖：
testCompile:配置依赖的jar，测试代码的编译和运行存在
testRuntime: 配置依赖的jar，只有测试代码的运行存在
上面四个配置的选用依据： 是否仅是运行阶段需要依赖或是否仅是测试阶段需要依赖
实战-logback依赖引用
到Maven仓库下找到logback:
logback在maven仓中的地址
在build.gradle中引入依赖：
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.12'
testCompile group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.3'
}
引入完成后，可以从gradle中看到所依赖的jar包：
引入之后就可以在test代码中使用 logback了，测试代码此处不在张贴
