gradle学习笔记(下)

构建脚本
group 分组 name 名字 version版本 用来确定依赖的坐标
build.gradle 中常用方法 apply[所需插件]、dependencies[所需依赖]、repositories[指定依赖仓库],task[自定义任务]
属性的配置方式 ext、 或者建立gradle.properties文件来声明属性

    taskdependsOn 声明任务依赖于上一个任务动作[会先执行所依赖的任务]    一个任务包含多个任务动作    doFirst[任务动作列表前添加动作]、doLast<<[任务动作列表后添加动作]  一个任务可以包含多个doFirst和doLast      自定义任务名称 存在于other 中。

构建生命周期: 初始化（初始化有哪些项目会添加到初始化中）->配置(确定执行动作顺序)->执行(执行动作代码)
也有提供初始化执行后执行定义代码 也有配置后执行自定义代码 …… 具体查看官方文档

依赖管理 :
工件坐标 :项目名 、模块名、版本号
常用仓库:mavenLocal（自己本地仓库）/mavenCentral/jcenter （公网的公共仓库,可以下载jar也可以自己上传jar）
自定义maven仓库 构建自己的私服
文件仓库:本地机器的路径也可以作为仓库
下载jar包顺序是按照配置文件中声明的仓库顺序来查找，如果查找到了 即下载 不继续往下查找

    依赖传递性: A依赖B B依赖C  则A就依赖C    依赖阶段: compile  runtime 编译依赖的运行时都会依赖 运行时依赖的编译时不一定依赖 运行时依赖扩于编译时依赖                比如jdbc的驱动类是属于运行时依赖，因为我们源码有它的接口，只需要运行的时候调用具体实现类即可                当然如果无法区分编译依赖和运行依赖，统一使用编译依赖 也没错。              testCompile testRuntime 测试时依赖的源码不一定依赖，但是源码依赖的测试一定依赖    版本冲突: gradle 默认以当前冲突中最高版本来解决版本冲突 ，所以一般不需要我们来关注        //修改版本冲突默认策略 ， 这样就能发现出现版本冲突了            configurations.all{                resolutionStrategy{                    failOnVersionConflict()                }            }            冲突解决方式1；排除低版本依赖                 //排除传递性依赖                compile('org.hibernate:hibernate-core:3.6.3.Final'){                    exclude(group:'org.slf4j',model:'slf4j-api')                }            冲突解决方式2: 强制指定各个冲突jar依赖的某个版本  (在修改版本冲突策略中加入force方法)                        configurations.all{                            resolutionStrategy{                                failOnVersionConflict()                                //指定该依赖统一都使用这个版本                                force 'org.slf4j:slf4j-api:1.7.22'                            }                        }                                        }            默认解决方式: 使用冲突中最高版本jar

多模块构建
settings.gradle 文件只能表示该父项目包含哪些模块
模块间的依赖:
dependencies {
//该模块依赖了modle模块(具有传递性依赖)
compile project (‘:modle’)
compile ‘org.codehaus.groovy:groovy-all:2.3.11’
testCompile group: ‘junit’, name: ‘junit’, version: ‘4.12’
}

根项目中的build.gradle文件中    allprojects{        //指定所有子项目依赖的插件        apply plugin: 'java'        sourceCompatibility=1.8        apply plugin: 'groovy'    }    //为所有子模块配置    subprojects{        //指定仓库        repositories {            //调用project的空参数方法    //        maven{    //    //            url:'私服地址'    //        }            mavenLocal()            mavenCentral()        }        //配置公共依赖        dependencies {            compile 'org.codehaus.groovy:groovy-all:2.3.11'            compile 'ch.qos.logback:logback-classic:1.2.1'            testCompile group: 'junit', name: 'junit', version: '4.12'        }    }web子模块build.gradle 文件中        dependencies {        //依赖service模块        compile project(':Service')    }    统一配置管理 在根项目下建立gradle.properties文件  可以定义子模块的版本信息     #定义子模块中的统一属性        group = 'demo'        version = '1.0-SNAPSHOT'    然后可以删除子模块中的group和version定义    根目录的一些任务    比如clean 它会执行整个子模块所有的clean任务  而子模块的clean任务只会执行和它相互关联的clean任务

自动化测试
建立garadle契约式目录
会在构建的时候自动执行测试方法 通过则继续构建 失败就报错

发布项目:

在根目录添加以下配置 gradle命令的根项目中会出现publish类型的一系列命令 可以执行发布工作

//发布到远程仓库的插件apply plugin: 'maven-publish'publishing {    //myPublish 是自己可以定义的    publications {        mavenJava(MavenPublication) {            //将那个模块或者项目 输出发布到远程仓库            groupId 'demo'            artifactId 'demo'            version '1.0-SNAPSHOT'            from components.java        }    }    //指定发布的仓库    repositories{        mavenLocal()    }    //指定发布的仓库 可以指定多个， 每个将会在gradle命令中多一个发布到不同库的命令//        repositories{//            maven{//                //远程名字//                name 'myRepo'//                //远程地址//                url ''//            }//        }}