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 ''
//            }
//        }

}