Gradle——依赖管理和多项目构建

依赖管理

这可能是没有必要专门写一篇的，毕竟看了下课程也太短了。
但是无所谓了，就记一下好了。
为什么要进行依赖管理？主要因为我们不想重复造轮子，但是在实际构建项目的过程中又不可避免地要使用外部类库以重用其现有功能。自动化的依赖管理可以明确依赖的版本，可以解决因传递性依赖而带来的版本冲突问题。

工件坐标

所谓工件，我们可以简单将其理解为一个外部依赖jar包，而坐标则是它的三个属性：group、name、version。通过这三个属性，我们可以唯一确定一个jar包。

仓库

如果用过maven的话，这是非常容易理解的概念，直观的说就是存放jar包的地方。
常用的有mavenCentral以及jcenter，也可以配置本地仓库mavenLocal；除此之外，还可以有第三方仓库，比如Jboss的、开源中国的等等。部分企业为内部业务代码安全考虑，会搭建内部maven仓库使用。

依赖的传递性

A——C，B——C，A和B可能因为依赖的版本不同而产生版本冲突。
举个栗子，如果我们需要引入logback-classic的依赖，要指明它依赖于logback-core，以及slf4j-api，如果在这样的情况下，我们需要再引入其他依赖，而这些依赖又依赖于logback-core以及slf4j-api，就有可能引发依赖版本冲突。对于依赖冲突的问题，我们通常可以查看依赖报告，然后排除掉传递性依赖，或者我们强制指定一个版本。Gradle默认将当前最高版本作为依赖类库。当然这个策略是可以修改的：

configurations.all{
    resolutionStrategy{
            failOnVersionConflict()
    }
}

这样，当发生版本冲突时，项目构建会因此失败，我们就可以发现版本冲突的问题，然后排除传递性依赖：

compile('org.hibernate:hibernate-core:3.6.3.Final'){
    exclude group:"org.slf4j",module:"slf4j-api"
    //transitive=false
    //下面的一般不用
}

强制指定某个版本：

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

多项目构建

项目模块化

企业项目中，包的层次和类的关系十分的复杂，把代码拆分成模块通常是最佳实践，这需要我们清晰地划分功能的边界，比较常见的，例如：业务逻辑和数据持久化的拆分。项目符合高内聚低耦合的要求时，模块化就变得比较容易，这是非常好的软件开发实践。这里我又想起了spring，它就清晰地分为了mvc、core等等模块。

配置子项目

配置要求

所有项目应用java插件；
web子项目打包成war；
所有项目添加日志功能logback（随意，其他日志实现也行）；
统一配置子模块，例如group。

栗子

并没有。
事实上我们可以IDE内新建多个模块，如果模块之间有依赖关系，那么在依赖管理内，需要配置好该依赖，与子项目的依赖使用：

//如此即可
compile project(:子项目名)

在settings.gradle文件内，有着根项目以及包含的子项目的树状图。

rootproject.name='xxx'
include 'yyy'
include 'aaa'

公共信息可以在根项目的build.gradle内配置
例如：

allprojects{
    apply plugin:'java'
    sourcesCompatibility:1.8
}

当然，在subprojects内也是可以的，刚好我们需要所有子项目都有日志实现，所以：
subprojects{
repositories{
mavenCentral()
}
dependencies{
compile ‘ch.qos.logback:logback-classic:xxxxx’
}
}
最后，还有如何配置group以及version。在根项目下新建gradle.properties，group以及version信息放置在该文件下即可，由于它是一个属性文件，所以我们键值对之间应当使用“=”。