生成task的依赖顺序和执行顺序

看懂基本构建脚本

创建一个gradle项目、打jar包、war包

apply plugin : 'war’使用的plugin去哪找呢，gradle官网

实战：gradle管理web程序和java程序

构建脚本

构建脚本中默认都是有个project实例的

本节概要如下

一、根据上节对项目的要求，对多项目进行配置优化

要求一：所有模块都应用Java插件

所有项目默认都应用Java插件，但是最好统一配置在根目录下。配置方式：在根项目的build.gradle使用allprojects方法

allprojects{

根据课程，自己手写了一份代码，大家可以拿去参考
https://gitee.com/StarsSky/todo

group:name:version

  1.基本概念：项目，任务，至少一个项目，多项目有   依赖关系

  2.项目：正在构建的组件。Gradle基于build.gradle实例化org.gradle.api.Project类，通过project变量隐式可用。

3.坐标：groupId,name,version   常用:apply,dependencies,repositories,task

4.task:包括任务动作，任务依赖，任务动作最小的工作单元。   dependsOn,doFirst,doLast 

5.一般不需要自定义task

hibermate-core-3.6.3 ->hibermate-anotations3.2.0-->slf4j1.5.8

 hibermate-core-3.6.3 ->slf4j1.6.1

本节概要如下

一、根据上节对项目的要求，对多项目进行配置优化

要求一：所有模块都应用Java插件

所有项目默认都应用Java插件，但是最好统一配置在根目录下。配置方式：在根项目的build.gradle使用allprojects方法

allprojects{
  apply plugin:'java'
  sourceCompatibility = 1.8
}

要求二：web子项目打包成war包

只给web模块的build.gradle配置：apply plugin:'war'

要求三：所有项目添加Logback日志功能

根项目没有代码，所以使用allprojects或者subprojects配置效果一样，这里就采用subprojects来试

tips：allprojects和subprojects的闭包里，都完全可以看作一个单独的build.gradle来写代码

要求四：统一配置group和version（之前提过ext和gradle.properties方式）

这里采用gradle.properties，在根目录创建gradle.properties，配置group和version即可

二、总结

总结一：子项目的build.gradle里只是配置项目自己的个性化的配置，共性的全都在根项目里一起配置了

总结二：根项目执行task，会同步执行所有子项目对应的task；也可以选择直接在单个项目下执行任务

本节概要如下

一、项目模块化

项目高内聚低耦合时，可以轻松地进行模块化。模块也就是module

二、实战前的知识铺垫

配置要求：1、所有项目添加logback日志功能；2、统一配置公共属性（group、version等）

项目范围：1、子项目包括刚刚划分的三个项目（model、repository、web），对应方法为subprojects；2、所有项目相比于子项目，多了一个根项目，所有项目对应方法为allprojects（子项目和所有项目，感觉都是从根项目的视角来看的）

三、多项目相关说明

模块间如何相互依赖？在dependencies里增加编译阶段依赖：

compile project(":model")

只有根项目有settings.gradle，里面除了原先的rootProject.name之外，还有三个include，对应三个子项目。settings.gradle就是用于多项目构建的，只是用来管理当前项目有哪些子项目

本文概要如下

一、解决依赖冲突的步骤：

1、查看依赖报告

2、通过排除传递性依赖解决冲突

3、或者强制指定一个版本来解决冲突

二、gradle的冲突解决策略

一般不需要手动处理依赖冲突，gradle默认会依赖发生冲突的较高版本的jar包

如何修改gradle的默认冲突解决策略（下例设定为发生冲突就失败）：

configuration.all{
  resolutionStrategy{
    failOnVersionConflict()
  }
}

三、冲突解决方式

冲突解决方式1：排除传递性依赖

在某个依赖下exclude排除某些jar包

冲突解决方式2：强制指定一个版本

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

tips：IDEA下查看依赖树的方法：执行help下的dependencies任务

本节概要如下

一、概述

描述：基于JVM的项目都需要依赖外部类库提供的功能。自动化的依赖管理可以明确依赖的版本，解决因传递性依赖带来的版本冲突

工件坐标（GAV）：group、artifactId、version三者，可以唯一确定一个jar包

常用仓库：公共仓库对应方法mavenCentral和jcenter，本地仓库对应方法mavenLoacal，实际开发中最常用的就是自定义maven仓库（maven私服），还有不推荐的文件仓库

依赖的传递性：C依赖B，B依赖A，则C依赖A

自动化依赖管理的场景（参考截图理解）：构建工具提供依赖管理功能，从远程仓库拉取jar包到本地仓库，给依赖配置（构建脚本比如build.gradle）使用

二、依赖管理的几个阶段

源代码两个阶段：compile编译阶段、runtime运行时阶段

测试代码的两个阶段：testCompile、testRuntime

各阶段的关系：编译阶段依赖的，运行时都会依赖；源代码阶段依赖的，测试代码阶段都会依赖。反之不成立

取舍：编译阶段不需要的依赖，可以放到运行时来依赖，比如jdbc的接口和实现类，后者在运行时依赖即可。粗暴的办法是，都设置为编译阶段依赖

本节主题：构建的生命周期

构建共有三个阶段：

1、初始化：Gradle根据构建脚本创建一个项目，并且在这个构建脚本中隐式可用。在多项目中，会把需要参与构建的项目（应该是指当前仙姑依赖的那些项目）也进行初始化

2、配置：根据配置代码（可以粗暴理解为，除了动作代码之外的所有代码）生成task的依赖顺序和执行顺序

3、执行：执行动作代码（动作代码里不能修改和定义任务的依赖，所以doFirst里不能放dependsOn），执行完后构建就结束了

gradle的灵活性：提供了钩子方法（Hook），在每个阶段之间都有对应的钩子方法。一般很少用到，知道它们的存在就可以了