关于我在写Gradle时我究竟在搞什么-技术圈

疫情原因，五一有些不爽，放假归来，怒更一贴。

上班第一天，被公司架构大佬分派了一个Event Mesh中间件的维护工作，本着面向薪资编程的初衷，打开了项目打算研究一下，发现了一个不得了的事情：

可以看到每个项目中找不到对于javaer来说熟悉的pom.xml，取而代之的是每个项目模块里都有一个build.gradle、gradle.properties，另外在项目根目录下还有一个setting.gradle.

很明显，项目没有采用maven而是用的Gradle来做版本依赖控制，没有按着公司规范进行，然后雷记想到:把这个事儿说出来，能换条命嘛好汉

提起Gradle，一把辛酸泪。为何出此言呢？且看分解:

·build.gradle:文件必须。定义了一个模块和编译用的tasks，它一般是放在项目的模块中，也可以放在项目的根目录用来作为编译结构全局设置。

·gradle.properties:文件必须。描述了哪一个模块需要参与构建。每一个多模块的构建都必须在项目结构的根目录中加入这个设置文件。

·setting.gradle:配置构建属性，不是必须的。

DEMO 4 build.gradle

task hello {//定义一个hello的task

doLast{//实现doLast方法

println 'Hello world!'

}

终端>gradle hello执行即可打印，实际使用时task之间是相互依赖的。所以存在一个task依赖另一个task，此时在task定义时加入dependsOn：

task hello << {

println ‘Hello world!’

}

task intro(dependsOn:hello) << {

println ‘i'm gradle’

}

Gradle插件

Gradle的设计理念是，所有有用的特性都由Gradle插件提供，例如编写一个Java项目时，需要使用到 Java 插件，它会将许多任务自动的加入到你项目里。Gradle本身提供了一系列的标准插件，无需多余配置只需要在你的build.gradle文件中加入 apply plugin: 'java'，便可以引入许多task，只需要使用对应的task即可进行项目构建：

·gradle build:编译整个项目，执行代码编译、代码检查和单元测试；

·gradle assemble:编译并打包代码，不运行代码检查和单元检测；

·gradle clean:删除build生成的目录和所有生成的文件；

·gradle check:编译并测试代码；

Gradle各个task关系图，可以发现build实际为将一批task批量执行:

外部依赖

做java开发时，我们有时会依赖第三方外部库，在gradle同样需要明确去哪里寻找，在 Gradle 中, JAR 文件位于一个仓库中，这里的仓库类似于maven 的仓库，首先指定maven的仓库地址：

repositories {
    mavenCentral()    
}

mavenCentral()是Gradle内置的一个maven仓库地址，加入maven仓库后，就可以直接加入maven仓库中的外部依赖，如果这个外部依赖不存在，gradle会联网去maven仓库中自动下载它，并将它缓存到本地，下次再使用时会优先从本地缓存中查找该依赖,引用一个外部依赖需要指定使用的group, name 和 version 属性，三者缺一不可。：

dependencies {
    compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
    // 简化写法  
    // compile 'commons-collections:commons-collections:3.2'
}

本地依赖：

Gradle也可以从本地目录中引入JAR包依赖，可以单一引入指定的某一JAR包，也可以引入某目录下所有的JAR包：

dependencies {    
    compile files('dir/file.jar')  
    compile fileTree(dir: 'libs', include: '*.jar')
}

项目依赖：

一个完整的项目由多个子项目构成。在Gradle中，使用文件settings.gradle定义当前项目的子项目。默认情况下，每个子项目的名称对应着当前操作系统目录下的一个子目录：

include 'sub-project1', 'sub-project2', 'sub-project3'

如sub-project1依赖sub-project2，则在sub-project1的build.gradle中加入以下配置即可：

dependencies {  
    compile project(':sub-project2')
}

依赖关系管理

gradle需要明确被构建或运行的项目，找到后将这些导入的文件视为项目的依赖；
gradle需要构建或打包项目，将这些导出的文件视为项目的发布；

例如在编译源码时项目需要Hibernate的某些jar包被加入到工程中，而在进行单元测试时还另需要Junit的某些jar被加入。这些被引入的jar包就是项目的依赖。Gradle允许对依赖进行相应的配置，通过不同的配置可以形成不同的依赖效果,例如：

    apply plugin: 'java'
    repositories {
        mavenCentral()
    }
    dependencies {
        compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
        testCompile group: 'junit', name: 'junit', version: '4.+'
    }

在项目编译时期，junit的jar包不会被引入，只有在单元测试时才会被引入。这样，就可以在不同的场景下加入相应的依赖关系，非常的灵活。Java 插件中定义了许多标准的配置：

compile        用来编译项目源代码的依赖
runtime        在运行时被生成的类使用的依赖。 默认的, 也包含了compile时的依赖。
testCompile    编译测试代码的依赖。 默认的, 包含runtime时的依赖和compile时的依赖。
testRuntime  运行测试所需要的依赖。 默认的, 包含上面三个依赖。

函数式编程_类型拆装及重载解析函数式编程关于二进制接口兼容性