上一篇咱们讲解了 Gradle 构建项目的生命周期，这一篇咱们来看下 Gradle 的另一个重要的知识点：依赖管理，那为什么需要依赖管理呢？
依赖管理
几乎所有基于 JVM 的软件项目都需要依赖外部的类库来重用现有的功能代码。自动化依赖管理可以明确依赖的版本，能解决传递性依赖带来的版本冲突问题。
而Gradle 就满足这两个条件，以下就来看下依赖管理的关键点。
依赖管理关键点
1. 工件坐标(jar 包标志)
- group : 指明 jar 包所在的分组
- name : 指明 jar 包的名称
- version: 指明 jar 包的版本
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.12'
// 简写
// testCompile 'junit:junit:4.12'
}
在 dependencies 中指明依赖的 jar 包
2. 仓库(jar 包的存放位置)
- 公共仓库(中央仓库)
Gradle 没有自己的中央仓库，可配置使用 Maven 的中央仓库：mavenCentral/jcenter - 私有仓库
配置从本地 maven 仓库中获取依赖的 jar 包，不远程加载 jar 包，使用 mavenLocal - 自定义 maven 仓库
自定义仓库来源，一般指向公司的 Maven 私服。 - 文件仓库
本地机器上的文件路径，一般不使用，没有意义。因为构建工具的目的就是去除本机的影响，可以在任何地方公用同一份仓库数据，跟本机关联上就没有太大的意义，当然特殊情况下除外。
repositories {
// 配置本地仓库
mvaenLocal()
// 配置中央仓库
// jcenter()
mavenCentral()
// 自定义私服地址
maven {
url ''
}
}
在 repositories 中配置仓库的指向，在这里面可配置多个仓库，会按配置的顺序去查找jar包，找到则获取，找不到继续到下一个配置的仓库去查找。一般是在最前面配置公司的私服，使用自定义仓库方式配置。
3. 依赖传递性
比如：A 依赖 B，如果 C 依赖 A，那么 C 依赖 B。
就是因为依赖的传递性，所以才会出现版本的冲突问题。以下通过一张图来了解下Gradle 的自动化依赖管理流程。
由图可得知，Gradle 工具从远程仓库下载 jar 包到本地仓库，Gradle 工具需要依赖配置文件，如果同一个 jar 经常使用会被存入到依赖缓存中。
4. 依赖阶段配置
在 build.gradle 中的 dependencies 中配置依赖，依赖分以下四种依赖：
源码依赖：compile，runtime
测试依赖：testCompile，runtime
关系图如下：
- compile 配置依赖的 jar，测试代码编译和运行以及源码运行一定存在。
- runtime 配置依赖的 jar，只有源码运行和测试运行存在。
- testCompile 配置依赖的 jar，测试代码的编译和运行存在。
- testRuntime 配置依赖的 jar，只有测试代码的运行存在。
以上的四种配置选用的主要判断依据是：是否仅是运行阶段需要依赖或是否仅是测试阶段需要依赖。
仅运行阶段需要依赖使用 runtime，如果仅是测试阶段需要依赖加 test 前缀 testCompile 或 testRuntime。
以上是依赖管理的配置和概念点的讲解，接下来咱们来实际配置一个依赖，来为项目加入一个logbok依赖。
5. 加入 logbok 依赖
5.1 到中央仓库查找 logbok 的配置
http://mvnrepository.com/search?q=logback
5.2 拷贝配置到 build.gradle 中配置依赖
dependencies {
testCompile 'junit:junit:4.12'
testCompile 'ch.qos.logback:logback-classic:1.2.3'
}
5.3 刷新导入
在 test 包下书写 MyTest.java 文件
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyTest {
private static final Logger LOGGER = LoggerFactory.getLogger(MyTest.class);
public static void main(String[] args) {
LOGGER.info("logback 测试");
}
}
以上咱们就把日志依赖的 jar 导入到了项目，现在项目就可以使用日志了。
logback 下的两个包为 logback 依赖的 jar 包，由于依赖的传递性，所以目前项目的测试代码也依赖了这两个包，比如slf4j。
如果此项目引入了其他的 jar 包，而这些 jar 也依赖了slf4j，但是版本不一样的情况下就存在了版本冲突问题，像版本冲突在开发中是经常遇到的，那么在 Gradle 中如何解决版本冲突呢？请期待下一篇 <<Gradle版本冲突问题>>。
