几乎所有基于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 plugin 私有仓库_jar


gradle工具根据*.gradle配置文件从远程仓库下载所需要的jar包并保存的本地仓库，如果同一个jar包经常使用，则会被存入到依赖缓存中

依赖阶段配置
在build.gradle中的dependencies中配置依赖

  1. 源码依赖：
    compile： 配置依赖的jar,测试代码编译和运行以及源码运行一定存在
    runtime：配置依赖的jar，只有源码运行和测试运行存在
  2. 测试依赖：
    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包：

gradle plugin 私有仓库_jar包_02


引入之后就可以在test代码中使用 logback了，测试代码此处不在张贴