详细学习如何用Gradle构建标准的java项目。第二部分。该学习记录基于Gradle官方网站资料。本篇参考链接如下：

编译代码

按照如下约定，可以使编译业务和测试代码变得很容易：

将业务代码放在src/main/java下将测试代码放在src/test/java下将业务代码所需依赖声明在compileOnly 或者implementation配置之下将测试代码所需依赖声明在testCompileOnly或者testImplementation配置之下执行compileJava任务与compileTestJava任务

自定义文件和路径

如果需要自定义代码文件的路径，可以利用上一章学习过的source sets。

sourceSets { // 默认定义main为业务代码的source sets main { java { srcDirs = ['src'] } } // 默认定义test为测试代码的source sets test { java { srcDirs = ['test'] } }}

如果不希望改变约定的路径，而是想在约定的路径外添加其他目录，可以使用如下方法：

sourceSets { // 默认定义main为业务代码的source sets main { java { // 使用srcDir方法为main source set添加代码路径 srcDir 'thirdParty/src/main/java' } }}

这里要注意，这里使用的是srcDir()方法，会添加路径。而如果使用srcDir属性，那么属性值会被覆盖。

改变编译选项

使用compileJava或者compileTestJava任务的时候，可以在方法内部改变编译选项。这两个任务都继承自JavaCompile类型。比如：

compileJava { // 使用增量化编译（个人理解就是如果代码与上次没有变化，那么不编译） options.incremental = true // 启动另外一个线程来编译代码 options.fork = true // 如果出现编译错误了，不会继续执行，而是中断整个构建 options.failOnError = false}

这里学习两个比较常用的选项：

sourceCompatibility：定义编译代码的jdk版本targetCompatibility：定义代码执行时的jdk版本，它决定了java字节码如何生成

关于选项的详细信息可以参照下面的链接：

Java版本对Gradle的影响Gradle不支持java1.5如果是java1.6和1.7需要配置很多任务，因为较新的项目使用的基本是1.8以上版本，所以这里不作为学习内容。分开编译独立代码

Gradle已经实现了分别编译不同的代码，比如业务代码main和测试代码test。但是如果工程需求的代码不属于这两个范围的时候，比如结合测试代码，就需要用到自定义source set。详细的例子在之后要学习的java testing章节。

那么除了结合测试以外，还有一些情况需要自定义source set：

需要编译一个特殊的类生成不存在于main和test的source set的class文件工程有必要需求管理资源（resources）

很多java的web工程需要一些资源文件，比如图像，js文件，xml配置等。一般情况下，这些资源文件不会做任何更改，直接拷贝到jar包或者war包的相应位置。默认情况下，这些资源文件都保存在src/java/resource文件夹，那么使用processResource任务就可以实现拷贝。自定义resource位置的时候，需要遵循如下规则：

资源文件放在src/[sourceSet]/resource文件夹下使用process[SourceSet]Resource任务来实现拷贝。这个任务名字中有source set的名字，会自己寻找资源位置、

processResource和process[SourceSet]Resource都是Copy类型的。

运行测试代码

Java插件提供了是单体测试变得简单的方法。它可以自动应用jnit或者TestNG。

提供自动的Test类型的测试任务test，它使用test source set生成html报告，包含了所有Test类型的任务的结果按照条件过滤需要执行的test可以自定义Test的测试任务

默认提供的test任务，仅仅针对test source set。如果需要执行其他source set的测试代码，需要自定义测试任务。关于如何定义测试任务以及测试任务的执行，后面的章节会学习到。

打包及发布

Java工程分为多种：类库，应用程序，网络应用程序，企业级应用程序等。它们的打包与发布都有各自的需求。Java插件只提供了jar任务，会将所有编译过的业务及测试代码打包进Jar包。

默认的jar任务可能不能满足需求，也可以自定义Jar类型的任务。比如下面的示例，只把业务代码打包进了jar包。这个任务被声明为Jar类型。

task sourcesJar(type: Jar) { // Jar的classifier，出现在jar文件的名字中 archiveClassifier = 'sources' // 指定打包对象 from sourceSets.main.allJava}

关于打包，还可以参照学习记录005的 4.建立归档文件（zip，tar等等）

关于各种种类工程的打包方式：

类库：使用jar任务，或者引入Java Library插件，使用api任务。应用程序：引入Application插件，使用assemble任务来生成zip或者tar文件。使用run来执行该应用程序网络应用程序：引入war插件，使用war任务来使工程变为war包企业级应用程序：引入Ear插件，使用ear任务来打包工程

改变Jar的清单（manifest）

无论是jar，war还是ear任务都有一个manifest属性，允许通过这个属性自定义包中的MANIFEST.MF文件。不了解这个文件作用可以自行百度，信息很多。

jar { manifest { attributes("Implementation-Title": "Gradle", "Implementation-Version": version) }}

关于manifest属性，详细可以参照如下链接：

也可以为多个jar包的生成指定统一的manifest信息：

ext.sharedManifest = manifest { attributes("Implementation-Title": "Gradle", "Implementation-Version": version)}task fooJar(type: Jar) { manifest = project.manifest { // 打包用到的manifest信息由变量shardManifest定义 from sharedManifest }}

另外可以使用manifest来将定义在多个文件中的内容整合到一个MANIFEST.MF文件中：

task barJar(type: Jar) { manifest { // 定义一个attributes，这里可以把它看做一个 attributes key1: 'value1' from sharedManifest, 'src/config/basemanifest.txt' // 下面的方法没有试验成功。 //from(['src/config/javabasemanifest.txt', 'src/config/libbasemanifest.txt']) { // eachEntry { details -> // if (details.baseValue != details.mergeValue) { // details.value = baseValue // } // if (details.key == 'foo') { // details.exclude() // } // } //} }}

Java插件提供了一个默认的生成javadoc的任务，名字就是javadoc。它是一个Javadoc类型的任务。它会默认为业务代码生成文档。

也可以自定义Javadoc类型的任务来生成文档。

task testJavadoc(type: Javadoc) { source = sourceSets.test.allJava}

Java插件的jar任务，javadoc方法都会默认输出路径是/build文件夹，那么需要提供一个清空这个文件夹的方法，以免每次手动清空。可以使用clean任务，它是Delete类型的任务。默认清空build文件夹中的内容。