翻譯項(xiàng)目請(qǐng)關(guān)注Github上的地址：
https://github.com/msdx/gradledoc
本文翻譯所在分支：
https://github.com/msdx/gradledoc/tree/2.0 。
在線瀏覽地址：
http://gradledoc.qiniudn.com/2.0/userguide/userguide.html 。
另外，Android 手機(jī)用戶可通過(guò)我寫(xiě)的一個(gè)程序?yàn)g覽文檔，帶緩存功能的，目前0.6開(kāi)發(fā)中版本兼容 Android 2.3以上系統(tǒng)，項(xiàng)目地址如下：
https://github.com/msdx/gradle-doc-apk
翻譯不易，轉(zhuǎn)載請(qǐng)注明本文在CSDN博客上的出處：
https://blog.csdn.net/maosidiaoxian/article/details/80140234

關(guān)于我對(duì)Gradle的翻譯，以Github上的項(xiàng)目及http://gradledoc.qiniudn.com 上的文檔為準(zhǔn)。如發(fā)現(xiàn)翻譯有誤的地方，將首先在以上兩個(gè)地方更新。因時(shí)間精力問(wèn)題，博客中發(fā)表的譯文基本不會(huì)同步修改。

第二十三章. Java 插件

Chapter?23.?The Java Plugin

Java 插件向項(xiàng)目添加 Java 編譯、測(cè)試和捆綁的功能。它是其他許多 Gradle 插件的基礎(chǔ)。?
The Java plugin adds Java compilation, testing and bundling capabilities to a project. It serves as the basis for many of the other Gradle plugins.

23.1. 用法

23.1.?Usage

要使用 Java 插件，請(qǐng)?jiān)跇?gòu)建腳本中加入以下內(nèi)容：
To use the Java plugin, include in your build script:

示例 23.1. 使用 Java 插件 - Example?23.1.?Using the Java plugin

build.gradle

apply plugin: 'java'

23.2 源集

23.2.?Source sets

Java 插件引入了一個(gè)源集的概念。源集只是一組源文件，它們被一起編譯和執(zhí)行。這些源文件可能包含 Java 源文件和資源文件，有些其他插件可以將 Groovy 和 Scala 源文件包含在源集中。一個(gè)源集有一個(gè)相關(guān)聯(lián)的編譯類路徑和運(yùn)行時(shí)類路徑。?
The Java plugin introduces the concept of a?source set. A source set is simply a group of source files which are compiled and executed together. These source files may include Java source files and resource files. Other plugins add the ability to include Groovy and Scala source files in a source set. A source set has an associated compile classpath, and runtime classpath.

源集的一個(gè)用途是，將源文件進(jìn)行邏輯上的分組，以描述它們的目的。例如，你可以使用一個(gè)源集來(lái)定義一個(gè)集成測(cè)試套件，也可以使用單獨(dú)的源集來(lái)定義項(xiàng)目的 API 和實(shí)現(xiàn)類。?
One use for source sets is to group source files into logical groups which describe their purpose. For example, you might use a source set to define an integration test suite, or you might use separate source sets to define the API and implementation classes of your project.

Java 插件定義了兩個(gè)標(biāo)準(zhǔn)源集，分別是?main?和?test。main?源集包含生產(chǎn)源代碼，將其編譯并組裝到 JAR 文件中。test?源集則包含了單元測(cè)試源代碼，它們將被編譯并使用 JUnit 或 TestNG 來(lái)執(zhí)行。?
The Java plugin defines two standard source sets, called?main?and?test. The?main?source set contains your production source code, which is compiled and assembled into a JAR file. The?test?source set contains your unit test source code, which is compiled and executed using JUnit or TestNG.

23.3. 任務(wù)

23.3.?Tasks

Java 插件向你的項(xiàng)目添加了大量的任務(wù)，如下所示。
The Java plugin adds a number of tasks to your project, as shown below.

表 23.1. Java 插件——任務(wù) - Table?23.1.?Java plugin - tasks

任務(wù)名稱 Task name	依賴于 Depends on	類型 Type	描述 Description
CompileJava	所有產(chǎn)生編譯類路徑的任務(wù)，也包括了?jar?任務(wù)，因?yàn)轫?xiàng)目依賴被包含在?compile?配置中。? All tasks which produce the compile classpath. This includes the?jar?task for project dependencies included in the?compile?configuration.	JavaCompile	使用 javac 編譯 Java 生產(chǎn)源文件。 Compiles production Java source files using javac.
processResources	-	Copy	把生產(chǎn)資源文件復(fù)制到生產(chǎn)類目錄中。 Copies production resources into the production classes directory.
classes	compileJava?和?processResources。有些插件會(huì)添加其他的編譯任務(wù)。? compileJava?and?processResources. Some plugins add additional compilation tasks.	Task	組裝生產(chǎn)類目錄。 Assembles the production classes directory.
compileTestJava	compile?任務(wù)，以及所有能產(chǎn)生測(cè)試編譯類路徑的任務(wù)。? compile, plus all tasks which produce the test compile classpath.	JavaCompile	使用 javac 編譯 Java 測(cè)試源文件。 Compiles test Java source files using javac.
processTestResources	-	Copy	把測(cè)試資源文件拷貝到測(cè)試類目錄中。 Copies test resources into the test classes directory.
testClasses	compileTestJava?和?processTestResources。有些插件會(huì)添加其他的測(cè)試編譯任務(wù)。? compileTestJava?and?processTestResources. Some plugins add additional test compilation tasks.	Task	組裝測(cè)試類目錄。 Assembles the test classes directory.
jar	compile	Jar	組裝 JAR 文件 Assembles the JAR file
javadoc	compile	Javadoc	使用 Javadoc 生成生產(chǎn)的 Java 源代碼的API文檔? Generates API documentation for the production Java source, using Javadoc
test	compile，?compileTest，以及所有產(chǎn)生測(cè)試運(yùn)行時(shí)類路徑的任務(wù)。? compile,?compileTest, plus all tasks which produce the test runtime classpath.	Test	使用 JUnit 或 TestNG 運(yùn)行單元測(cè)試。 Runs the unit tests using JUnit or TestNG.
uploadArchives	產(chǎn)生在?archives?中所配置的工件的任務(wù)，包括?jar。? The tasks which produce the artifacts in the?archives?configuration, including?jar.	Upload	上傳在?archives?中所配置的工件，包括 JAR 文件。 Uploads the artifacts in the?archives?configuration, including the JAR file.
clean	-	Delete	刪除項(xiàng)目的構(gòu)建目錄。 Deletes the project build directory.
cleanTaskName	-	Delete	刪除指定任務(wù)生成的輸出文件。例如?cleanJar?將刪除由該?jar?任務(wù)創(chuàng)建的 JAR 文件，而?cleanTest?將刪除由該?test?任務(wù)創(chuàng)建的測(cè)試結(jié)果。? Deletes the output files produced by the specified task. For example?cleanJar?will delete the JAR file created by the?jar?task, and?cleanTest?will delete the test results created by the?test?task.

對(duì)于你添加到項(xiàng)目中的每一個(gè)源集，Java 插件將添加以下的編譯任務(wù)：
For each source set you add to the project, the Java plugin adds the following compilation tasks:

表 23.2. Java 插件——源集任務(wù) - Table?23.2.?Java plugin - source set tasks

任務(wù)名稱 Task name	依賴于 Depends on	類型 Type	描述 Description
compileSourceSetJava	所有產(chǎn)生源集編譯類路徑的任務(wù)。? All tasks which produce the source set's compile classpath.	JavaCompile	使用 javac 編譯給定的源集中的 Java 源文件。 Compiles the given source set's Java source files using javac.
processSourceSetResources	-	Copy	將給定源集的資源文件復(fù)制到類目錄中。 Copies the given source set's resources into the classes directory.
sourceSetClasses	compileSourceSetJava?和?processSourceSetResources。有些插件還為源集添加了其他的編譯任務(wù)。? compileSourceSetJava?and?processSourceSetResources. Some plugins add additional compilation tasks for the source set.	Task	組裝給定源集的類目錄。 Assembles the given source set's classes directory.

Java 插件還增加了大量構(gòu)成項(xiàng)目生命周期的任務(wù)：
The Java plugin also adds a number of tasks which form a lifecycle for the project:

表 23.3. Java 插件——生命周期任務(wù) - Table?23.3.?Java plugin - lifecycle tasks

任務(wù)名稱 Task name	依賴于 Depends on	類型 Type	描述 Description
assemble	項(xiàng)目中的所有歸檔任務(wù)，包括?jar。有些插件會(huì)向項(xiàng)目添加另外的歸檔任務(wù)。? All archive tasks in the project, including?jar. Some plugins add additional archive tasks to the project.	Task	組裝項(xiàng)目中所有的歸檔文件。 Assembles all the archives in the project.
check	項(xiàng)目中的所有驗(yàn)證任務(wù)，包括?test。有些插件會(huì)向項(xiàng)目添加另外的驗(yàn)證任務(wù)。? All verification tasks in the project, including?test. Some plugins add additional verification tasks to the project.	Task	執(zhí)行項(xiàng)目中所有的驗(yàn)證任務(wù)。 Performs all verification tasks in the project.
build	check?和?assemble? check?and?assemble	Task	執(zhí)行完整的項(xiàng)目構(gòu)建。 Performs a full build of the project.
buildNeeded	build?任務(wù)，以及在?testRuntime?配置的所有項(xiàng)目庫(kù)依賴項(xiàng)的?build?任務(wù)。? build?and?build?tasks in all project lib dependencies of the?testRuntimeconfiguration.	Task	執(zhí)行項(xiàng)目本身及它所依賴的其他所有項(xiàng)目的完整構(gòu)建。 Performs a full build of the project and all projects it depends on.
buildDependents	build?任務(wù)，以及在?testRuntime?配置中對(duì)此項(xiàng)目有庫(kù)依賴的所有項(xiàng)目的?build?任務(wù)。? build?and?build?tasks in all projects with a project lib dependency on this project in a?testRuntime?configuration.	Task	執(zhí)行項(xiàng)目本身及依賴它的其他所有項(xiàng)目的完整構(gòu)建。 Performs a full build of the project and all projects which depend on it.
buildConfigurationName	生成?ConfigurationName?配置里的工件的任務(wù)。? The tasks which produce the artifacts in configuration?ConfigurationName.	Task	組裝指定配置的工件。該任務(wù)由 Base 插件添加，并由 Java 插件隱式應(yīng)用。? Assembles the artifacts in the specified configuration. The task is added by the Base plugin which is implicitly applied by the Java plugin.
uploadConfigurationName	上傳?ConfigurationName?配置中的工件的任務(wù)。? The tasks which uploads the artifacts in configuration?ConfigurationName.	Upload	以指定的配置組裝并上傳工件。該任務(wù)由 Base 插件添加，并由 Java 插件隱式應(yīng)用。? Assembles and uploads the artifacts in the specified configuration. The task is added by the Base plugin which is implicitly applied by the Java plugin.

下圖顯示了這些任務(wù)之間的關(guān)系。
The following diagram shows the relationships between these tasks.

圖 23.1. Java 插件——任務(wù) - Figure?23.1.?Java plugin - tasks

23.4. 項(xiàng)目布局

23.4.?Project layout

Java 插件會(huì)假定如下所示的項(xiàng)目布局。這些目錄都不需要一定的存在在，或是里面有什么內(nèi)容。 Java插件不管發(fā)現(xiàn)什么都將會(huì)進(jìn)行編譯，并處理缺失的任何內(nèi)容。?
The Java plugin assumes the project layout shown below. None of these directories need exist or have anything in them. The Java plugin will compile whatever it finds, and handles anything which is missing.

表 23.4. Java 插件——默認(rèn)項(xiàng)目布局 - Table?23.4.?Java plugin - default project layout

目錄 Directory	意義 Meaning
src/main/java	Java 生產(chǎn)源代碼 Production Java source
src/main/resources	生產(chǎn)資源 Production resources
src/test/java	Java 測(cè)試源代碼 Test Java source
src/test/resources	測(cè)試資源 Test resources
src/sourceSet/java	給定源集的 Java 源代碼 Java source for the given source set
src/sourceSet/resources	給定源集的資源 Resources for the given source set

23.4.1. 更改項(xiàng)目布局

23.4.1.?Changing the project layout

你可以通過(guò)配置適當(dāng)?shù)脑醇瘉?lái)配置項(xiàng)目的布局，這點(diǎn)將在下面的章節(jié)中詳細(xì)討論。以下是一個(gè)簡(jiǎn)單的例子，展示如何改變 main Java 和資源源目錄。?
You configure the project layout by configuring the appropriate source set. This is discussed in more detail in the following sections. Here is a brief example which changes the main Java and resource source directories.

示例 23.2. 自定義 Java 源代碼布局 - Example?23.2.?Custom Java source layout

build.gradle

sourceSets {main {java {srcDir 'src/java'}resources {srcDir 'src/resources'}} }

23.5. 依賴管理

23.5.?Dependency management

Java 插件向項(xiàng)目添加了一些依賴配置，如下表所示。它將這些配置指定一些任務(wù)，如?compileJava?和?test。?
The Java plugin adds a number of dependency configurations to your project, as shown below. It assigns those configurations to tasks such as?compileJava?and?test.

表23.5. Java插件 ??- 依賴配置 - Table?23.5.?Java plugin - dependency configurations

名稱 Name	繼承自 Extends	在哪些任務(wù)中使用 Used by tasks	意義 Meaning
compile	-	CompileJava	編譯時(shí)依賴 Compile time dependencies
runtime	compile	-	運(yùn)行時(shí)依賴 Runtime dependencies
testCompile	compile	compileTestJava	用于編譯測(cè)試代碼的其他依賴 Additional dependencies for compiling tests.
testRuntime	runtime, testCompile	test	只用于運(yùn)行測(cè)試的其他依賴 Additional dependencies for running tests only.
archives	-	uploadArchives	由本項(xiàng)目產(chǎn)生的工件（如 jar 包）。 Artifacts (e.g. jars) produced by this project.
default	runtime	-	依賴于本項(xiàng)目的另一個(gè)項(xiàng)目所使用的默認(rèn)配置。包含此項(xiàng)目運(yùn)行時(shí)所需的工件和依賴。? The default configuration used by a project dependency on this project. Contains the artifacts and dependencies required by this project at runtime.

圖 23.2. Java 插件——依賴配置 - Figure?23.2.?Java plugin - dependency configurations

對(duì)于你添加到項(xiàng)目中的每個(gè)源集，Java 插件都會(huì)添加以下的依賴配置：
For each source set you add to the project, the Java plugins adds the following dependency configurations:

表 23.6. Java 插件——源集依賴配置 - Table?23.6.?Java plugin - source set dependency configurations

名稱 Name	繼承自 Extends	在哪些任務(wù)中使用 Used by tasks	意義 Meaning
sourceSetCompile	-	compileSourceSetJava	給定源集的編譯時(shí)依賴 Compile time dependencies for the given source set
sourceSetRuntime	sourceSetCompile	-	給定源集的運(yùn)行時(shí)依賴 Runtime time dependencies for the given source set

23.6. 約定屬性

23.6.?Convention properties

Java 插件向項(xiàng)目添加了許多約定屬性，如下表所示。你可以在構(gòu)建腳本中使用這些屬性，就像它們是 project 對(duì)象里的屬性一樣（見(jiàn)《第 21.3 節(jié)，“約定”》）。?
The Java plugin adds a number of convention properties to the project, shown below. You can use these properties in your build script as though they were properties of the project object (see?Section?21.3, “Conventions”).

表 23.7. Java 插件——目錄屬性 - Table?23.7.?Java plugin - directory properties

屬性名稱 Property name	類型 Type	默認(rèn)值 Default value	描述 Description
reportsDirName	String	reports	相對(duì)于構(gòu)建目錄，生成報(bào)告的目錄的名稱。? The name of the directory to generate reports into, relative to the build directory.
reportsDir	File?（只讀）? File?(read-only)	buildDir/reportsDirName	要生成報(bào)告的目錄。? The directory to generate reports into.
testResultsDirName	String	test-results	相對(duì)于構(gòu)建目錄，生成測(cè)試結(jié)果.xml 文件的目錄名稱。? The name of the directory to generate test result .xml files into, relative to the build directory.
testResultsDir	File?（只讀）? File?(read-only)	buildDir/testResultsDirName	生成測(cè)試結(jié)果.xml 文件的目錄。? The directory to generate test result .xml files into.
testReportDirName	String	tests	相對(duì)于報(bào)告目錄，生成測(cè)試報(bào)告的目錄的名稱。? The name of the directory to generate the test report into, relative to the reports directory.
testReportDir	File?（只讀）? File?(read-only)	reportsDir/testReportDirName	生成測(cè)試報(bào)告的目錄。? The directory to generate the test report into.
libsDirName	String	libs	相對(duì)于構(gòu)建目錄，生成庫(kù)的目錄的名稱。? The name of the directory to generate libraries into, relative to the build directory.
libsDir	File?（只讀）? File?(read-only)	buildDir/libsDirName	要生成庫(kù)的目錄。? The directory to generate libraries into.
distsDirName	String	distributions	相對(duì)于構(gòu)建目錄的目錄名稱，該目錄用于生成分發(fā)的文件。? The name of the directory to generate distributions into, relative to the build directory.
distsDir	File?（只讀）? File?(read-only)	buildDir/distsDirName	生成分發(fā)文件的目錄。? The directory to generate distributions into.
docsDirName	String	docs	相對(duì)于構(gòu)建目錄的目錄名稱，該目錄用于生成文檔。? The name of the directory to generate documentation into, relative to the build directory.
docsDir	File?（只讀）? File?(read-only)	buildDir/docsDirName	用于生成文檔的目錄。? The directory to generate documentation into.
dependencyCacheDirName	String	dependency-cache	相對(duì)于構(gòu)建目錄的目錄名稱，該目錄用于緩存源代碼的依賴信息。? The name of the directory to use to cache source dependency information, relative to the build directory.
dependencyCacheDir	File?（只讀）? File?(read-only)	buildDir/dependencyCacheDirName	用于緩存源代碼的依賴信息的目錄。? The directory to use to cache source dependency information.

表 23.8. Java 插件——其他屬性 - Table?23.8.?Java plugin - other properties

屬性名稱 Property name	類型 Type	默認(rèn)值 Default value	描述 Description
sourceSets	SourceSetContainer?（只讀） SourceSetContainer?(read-only)	不為 null Not null	包含項(xiàng)目的源集。 Contains the project's source sets.
sourceCompatibility	JavaVersion。也可以使用字符串或數(shù)字來(lái)設(shè)置，如?'1.5'?或?1.5。? JavaVersion. Can also set using a String or a Number, e.g.?'1.5'?or?1.5.	當(dāng)前所使用的 JVM 的值 Value of the current used JVM	當(dāng)編譯 Java 源代碼時(shí)所使用的 Java 版本兼容性。 Java version compatibility to use when compiling Java source.
targetCompatibility	JavaVersion。也可以使用字符串或數(shù)字來(lái)設(shè)置，如?'1.5'?或?1.5。? JavaVersion. Can also set using a String or Number, e.g.?'1.5'?or?1.5.	sourceCompatibility	要生成的類的 Java 版本。 Java version to generate classes for.
archivesBaseName	String	projectName	像 JAR 或 ZIP 文件這樣的工件的基本名稱。 The basename to use for archives, such as JAR or ZIP files.
manifest	Manifest	一個(gè)空的清單 an empty manifest	包含在所有 JAR 文件中的清單。 The manifest to include in all JAR files.

這些屬性由?JavaPluginConvention?和BasePluginConvention?這些類型的約定對(duì)象提供。?
These properties are provided by convention objects of type?JavaPluginConvention, and?BasePluginConvention.

23.7.?使用源集

23.7.?Working with source sets

你可以使用?sourceSets?屬性訪問(wèn)項(xiàng)目的源集。這是項(xiàng)目源集的容器，它的類型是?SourceSetContainer。除此之外，還有一個(gè)?sourceSets{}?腳本塊，可以傳入一個(gè)閉包來(lái)配置源集容器。源集容器的使用方式與其他的容器幾乎一樣，例如?tasks。?
You can access the source sets of a project using the?sourceSets?property. This is a container for the project's source sets, of type?SourceSetContainer. There is also a?sourceSets { }?script block, which you can pass a closure to configure the source set container. The source set container works pretty much the same way as other containers, such as?tasks.

示例 23.3. 訪問(wèn)源集 - Example?23.3.?Accessing a source set

build.gradle

// Various ways to access the main source set println sourceSets.main.output.classesDir println sourceSets['main'].output.classesDir sourceSets {println main.output.classesDir } sourceSets {main {println output.classesDir} }// Iterate over the source sets sourceSets.all {println name }

要配置一個(gè)現(xiàn)有的源集，你只需要使用上面的其中一種訪問(wèn)方法來(lái)設(shè)置源集的屬性。這些屬性將在下文中進(jìn)行介紹。以下是配置main 的 Java 和資源目錄的示例：
To configure an existing source set, you simply use one of the above access methods to set the properties of the source set. The properties are described below. Here is an example which configures the main Java and resources directories:

示例 23.4. 配置源集的源代碼目錄 - Example?23.4.?Configuring the source directories of a source set

build.gradle

sourceSets {main {java {srcDir 'src/java'}resources {srcDir 'src/resources'}} }

23.7.1. 源集屬性

23.7.1.?Source set properties

下表列出了一些重要的源集屬性。你可以在 API 文檔中找到更多有關(guān)?SourceSet?的詳細(xì)信息。?
The following table lists some of the important properties of a source set. You can find more details in the API documentation for?SourceSet.

表 23.9. Java 插件——源集屬性 - Table?23.9.?Java plugin - source set properties

屬性名稱 Property name	類型 Type	默認(rèn)值 Default value	描述 Description
name	String?（只讀）? String?(read-only)	不為 null? Not null	用來(lái)確定一個(gè)源集的源集名稱。? The name of the source set, used to identify it.
output	SourceSetOutput?（只讀）? SourceSetOutput?(read-only)	不為 null? Not null	源集的輸出文件，包含其編譯過(guò)的類和資源。? The output files of the source set, containing its compiled classes and resources.
output.classesDir	File	buildDir/classes/name	生成該源集的類的目錄。? The directory to generate the classes of this source set into.
output.resourcesDir	File	buildDir/resources/name	生成該源集的資源的目錄。? The directory to generate the resources of this source set into.
compileClasspath	FileCollection	compileSourceSet?配置。? compileSourceSet?configuration.	編譯該源集的源文件時(shí)使用的類路徑。? The classpath to use when compiling the source files of this source set.
runtimeClasspath	FileCollection	output?+?runtimeSourceSet?配置。? output?+?runtimeSourceSetconfiguration.	執(zhí)行此源集的類時(shí)使用的類路徑。? The classpath to use when executing the classes of this source set.
java	SourceDirectorySet?（只讀）? SourceDirectorySet?(read-only)	不為 null? Not null	此源集的 Java 源文件。僅包含 Java 源目錄中找到的?.java?文件，并排除所有其他文件。? The Java source files of this source set. Contains only?.java?files found in the Java source directories, and excludes all other files.
java.srcDirs	Set<File>?？梢允褂谩兜?16.5 節(jié)，“指定一組輸入文件”》中所講到的任何一種方法來(lái)設(shè)置。? Set<File>. Can set using anything described in?Section?16.5, “Specifying a set of input files”.	[projectDir/src/name/java]	該源目錄包含了此源集的所有 Java 源文件。? The source directories containing the Java source files of this source set.
resources	SourceDirectorySet?（只讀）? SourceDirectorySet?(read-only)	不為 null? Not null	此源集的資源。僅包含資源，并且排除在資源源目錄中找到的所有?.java?文件。其他插件（如 Groovy 插件）會(huì)從此集合中排除其他類型的文件。? The resources of this source set. Contains only resources, and excludes any?.java?files found in the resource source directories. Other plugins, such as the Groovy plugin, exclude additional types of files from this collection.
resources.srcDirs	Set<File>。可以使用《第 16.5 節(jié)，“指定一組輸入文件”》中所講到的任何一種方法來(lái)設(shè)置。? Set<File>. Can set using anything described in?Section?16.5, “Specifying a set of input files”.	[projectDir/src/name/resources]	包含此源集資源的源目錄。? The source directories containing the resources of this source set.
allJava	SourceDirectorySet?（只讀）? SourceDirectorySet?(read-only)	java	該源集的所有?.java?文件。有些插件，如Groovy 插件，會(huì)將其他 Java 源文件添加到此集合中。? All?.java?files of this source set. Some plugins, such as the Groovy plugin, add additional Java source files to this collection.
allSource	SourceDirectorySet?（只讀）? SourceDirectorySet?(read-only)	resources + java	該源集的所有源文件，包括所有資源文件和 Java 源文件。有些插件（如 Groovy 插件）會(huì)將其他源文件添加到此集合中。? All source files of this source set. This include all resource files and all Java source files. Some plugins, such as the Groovy plugin, add additional source files to this collection.

23.7.2. 定義新的源集

23.7.2.?Defining new source sets

要定義一個(gè)新的源集，你只需在?sourceSets {}?塊引用它。示例如下：?
To define a new source set, you simply reference it in the?sourceSets { }?block. Here's an example:

示例 23.5. 定義一個(gè)源集 - Example?23.5.?Defining a source set

build.gradle

sourceSets {intTest }

當(dāng)你定義一個(gè)新的源集時(shí)，Java 插件會(huì)為該源集添加一些依賴配置，如表 23.6，“Java 插件——源集依賴性配置”所示。你可以使用這些配置來(lái)定義源集的編譯和運(yùn)行時(shí)依賴。?
When you define a new source set, the Java plugin adds some dependency configurations for the source set, as shown in?Table?23.6, “Java plugin - source set dependency configurations”. You can use these configurations to define the compile and runtime dependencies of the source set.

示例 23.6. 定義源集依賴 - Example?23.6.?Defining source set dependencies

build.gradle

sourceSets {intTest }dependencies {intTestCompile 'junit:junit:4.11'intTestRuntime 'org.ow2.asm:asm-all:4.0' }

Java 插件還添加了大量的任務(wù)用于組裝源集的類，如表 23.2，“Java 插件——源集任務(wù)”所示。例如，對(duì)于一個(gè)名為?intTest?的源集，你可以通過(guò)運(yùn)行gradle intTestClasses來(lái)編譯 int 測(cè)試類。?
The Java plugin also adds a number of tasks which assemble the classes for the source set, as shown in?Table?23.2, “Java plugin - source set tasks”. For example, for a source set called?intTest, you can run?gradle intTestClasses?to compile the int test classes.

示例 23.7. 編譯源集 - Example?23.7.?Compiling a source set

gradle intTestClasses?的輸出結(jié)果
Output of?gradle intTestClasses

> gradle intTestClasses :compileIntTestJava :processIntTestResources :intTestClassesBUILD SUCCESSFULTotal time: 1 secs

23.7.3. 一些源集的范例

23.7.3.?Some source set examples

添加一個(gè)包含源集的類的 JAR 包
Adding a JAR containing the classes of a source set:

示例 23.8. 為一個(gè)源集組裝一個(gè) JAR 文件 - Example?23.8.?Assembling a JAR for a source set

build.gradle

task intTestJar(type: Jar) {from sourceSets.intTest.output }

為一個(gè)源集生成 Javadoc：
Generating Javadoc for a source set:

示例 23.9. 為一個(gè)源集生成 Javadoc： - Example?23.9.?Generating the Javadoc for a source set

build.gradle

task intTestJavadoc(type: Javadoc) {source sourceSets.intTest.allJava }

添加測(cè)試套件以運(yùn)行源集里的測(cè)試
Adding a test suite to run the tests in a source set:

示例 23.10. 運(yùn)行源集里的測(cè)試 - Example?23.10.?Running tests in a source set

build.gradle

task intTest(type: Test) {testClassesDir = sourceSets.intTest.output.classesDirclasspath = sourceSets.intTest.runtimeClasspath }

23.8. Javadoc

23.8.?Javadoc

Javadoc?任務(wù)是?Javadoc?的一個(gè)實(shí)例。它支持核心 javadoc 的參數(shù)選項(xiàng)，以及在 Javadoc 可執(zhí)行文件的參考文檔中描述的標(biāo)準(zhǔn) doclet 參數(shù)選項(xiàng)。對(duì)于所支持的 Javadoc 參數(shù)選項(xiàng)的完整列表，請(qǐng)參考下面的類的 API 文檔：?CoreJavadocOptions?和?StandardJavadocDocletOptions。?
The?javadoc?task is an instance of?Javadoc. It supports the core javadoc options and the options of the standard doclet described in the?reference documentation?of the Javadoc executable. For a complete list of supported Javadoc options consult the API documentation of the following classes:?CoreJavadocOptions?and?StandardJavadocDocletOptions.

表 23.10. Java 插件—— Javadoc 屬性 - Table?23.10.?Java plugin - Javadoc properties

任務(wù)屬性 Task Property	類型 Type	默認(rèn)值 Default Value
classpath	FileCollection	sourceSets.main.output + sourceSets.main.compileClasspath
source	FileTree。可以使用《第 16.5 節(jié)，“指定一組輸入文件”》中所講到的任何一種方法來(lái)設(shè)置。 FileTree. Can set using anything described in?Section?16.5, “Specifying a set of input files”.	sourceSets.main.allJava
destinationDir	File	docsDir/javadoc
title	String	項(xiàng)目的名稱和版本 The name and version of the project

23.9.?Clean

23.9.?Clean

clean?任務(wù)是?Delete?的一個(gè)實(shí)例。它只是刪除由?dir?屬性表示的目錄。?
The?clean?task is an instance of?Delete. It simply removes the directory denoted by its?dir?property.

表 23.11. Java 插件—— Clean 屬性 - Table?23.11.?Java plugin - Clean properties

任務(wù)屬性 Task Property	類型 Type	默認(rèn)值 Default Value
dir	File	buildDir

23.10.?Resources

23.10.?Resources

Java 插件使用?Copy?任務(wù)進(jìn)行資源的處理，它為項(xiàng)目中的每個(gè)源集添加一個(gè)實(shí)例。你可以在《第 16.6 節(jié)，“復(fù)制文件”》找到更多關(guān)于復(fù)制任務(wù)的信息。?
The Java plugin uses the?Copy?task for resource handling. It adds an instance for each source set in the project. You can find out more about the copy task in?Section?16.6, “Copying files”.

表 23.12. Java 插件—— ProcessResources 屬性 - Table?23.12.?Java plugin - ProcessResources properties

任務(wù)屬性 Task Property	類型 Type	默認(rèn)值 Default Value
srcDirs	Object?？梢允褂谩兜?16.5 節(jié)，“指定一組輸入文件”》中所講到的任何一種方法來(lái)設(shè)置。 Object. Can set using anything described in?Section?16.5, “Specifying a set of input files”.	sourceSet.resources
destinationDir	File。可以使用《第 16.1 節(jié)，“查找文件”》中所述的任何設(shè)置。 File. Can set using anything described in?Section?16.1, “Locating files”.	sourceSet.output.resourcesDir

23.11.?CompileJava

23.11.?CompileJava

Java 插件為項(xiàng)目里的每一個(gè)源集添加一個(gè)?JavaCompile?實(shí)例。一些最常見(jiàn)的配置選項(xiàng)如下所示。?
The Java plugin adds a?JavaCompile?instance for each source set in the project. Some of the most common configuration options are shown below.

表 23.13. Java 插件—— Compile 屬性 - Table?23.13.?Java plugin - Compile properties

任務(wù)屬性 Task Property	類型 Type	默認(rèn)值 Default Value
classpath	FileCollection	sourceSet.compileClasspath
source	FileTree?？梢允褂谩兜?16.5 節(jié)，“指定一組輸入文件”》中所講到的任何一種方法來(lái)設(shè)置。 FileTree. Can set using anything described in?Section?16.5, “Specifying a set of input files”.	sourceSet.java
destinationDir	File.	sourceSet.output.classesDir

默認(rèn)情況下，Java 編譯器在 Gradle 進(jìn)程中運(yùn)行。將?options.fork?設(shè)置為?true?將使得在一個(gè)單獨(dú)的進(jìn)程中進(jìn)行編譯。在Ant javac 任務(wù)的情況中，意味著每個(gè)編譯任務(wù)都會(huì) fork 一個(gè)新進(jìn)程，這樣就會(huì)使編譯變慢。相反，Gradle 的直接編譯器集成（見(jiàn)上文）將盡可能地重用相同的編譯器進(jìn)程。在這兩種情況下，使用?options.forkOptions?指定的所有 fork 選項(xiàng)都將得到重視。?
By default, the Java compiler runs in the Gradle process. Setting?options.fork?to?true?causes compilation to occur in a separate process. In the case of the Ant javac task, this means that a new process will be forked for each compile task, which can slow down compilation. Conversely, Gradle's direct compiler integration (see above) will reuse the same compiler process as much as possible. In both cases, all fork options specified with?options.forkOptions?will be honored.

23.12.?Test

23.12.?Test

test?任務(wù)是?Test?的一個(gè)實(shí)例。它會(huì)自動(dòng)檢測(cè)并執(zhí)行?test?源集中的所有單元測(cè)試。測(cè)試執(zhí)行完成后，它還會(huì)生成一個(gè)報(bào)告。它同時(shí)支持 JUnit 和 TestNG，可以看一看?test?的完整 API。?
The?test?task is an instance of?Test. It automatically detects and executes all unit tests in the?test?source set. It also generates a report once test execution is complete. JUnit and TestNG are both supported. Have a look at?Testfor the complete API.

23.12.1. 測(cè)試執(zhí)行

23.12.1.?Test execution

測(cè)試在單獨(dú)的 JVM 進(jìn)程中執(zhí)行，與主構(gòu)建進(jìn)程隔離。Test?任務(wù)的 API 允許你對(duì)這種情況進(jìn)行一些控制。?
Tests are executed in a separate JVM, isolated from the main build process. The?Test?task's API allows you some control over how this happens.

有很多屬性可以控制測(cè)試進(jìn)程的啟動(dòng)，包括系統(tǒng)屬性、JVM 參數(shù)以及要使用的Java 可執(zhí)行文件。?
There are a number of properties which control how the test process is launched. This includes things such as system properties, JVM arguments, and the Java executable to use.

你可以指定是否要并行執(zhí)行測(cè)試。Gradle 通過(guò)同時(shí)運(yùn)行多個(gè)測(cè)試進(jìn)程來(lái)提供并行測(cè)試的執(zhí)行。每個(gè)測(cè)試進(jìn)程一次只執(zhí)行一個(gè)測(cè)試，所以通常不需要為測(cè)試做任何特殊的配置就可以利用這一點(diǎn)。maxParallelForks?屬性指定了在給定的任何時(shí)間可以運(yùn)行的最大測(cè)試進(jìn)程數(shù)。默認(rèn)值為1，即不并行執(zhí)行測(cè)試。?
You can specify whether or not to execute your tests in parallel. Gradle provides parallel test execution by running multiple test processes concurrently. Each test process executes only a single test at a time, so you generally don't need to do anything special to your tests to take advantage of this. The?maxParallelForks?property specifies the maximum number of test processes to run at any given time. The default is 1, that is, do not execute the tests in parallel.

測(cè)試進(jìn)程程會(huì)將?org.gradle.test.worker?系統(tǒng)屬性設(shè)置為該測(cè)試進(jìn)程的一個(gè)唯一標(biāo)識(shí)符，這個(gè)標(biāo)識(shí)符可以用于文件名稱或其他資源標(biāo)識(shí)符。?
The test process sets the?org.gradle.test.worker?system property to a unique identifier for that test process, which you can use, for example, in files names or other resource identifiers.

你可以指定在執(zhí)行了一定數(shù)量的測(cè)試類之后，重新啟動(dòng)測(cè)試進(jìn)程。這是一個(gè)很有用的替代方案，可以讓你的測(cè)試進(jìn)程有非常大的堆內(nèi)存。forkEvery?屬性指定了要在測(cè)試進(jìn)程中執(zhí)行的最大測(cè)試類的數(shù)量。默認(rèn)是在每個(gè)測(cè)試進(jìn)程中執(zhí)行的測(cè)試數(shù)量不限。
You can specify that test processes should be restarted after it has executed a certain number of test classes. This can be a useful alternative to giving your test process a very large heap. The?forkEvery?property specifies the maximum number of test classes to execute in a test process. The default is to execute an unlimited number of tests in each test process.

該任務(wù)有一個(gè)?ignoreFailures?屬性，用于控制測(cè)試失敗時(shí)的行為。測(cè)試任務(wù)始終執(zhí)行它檢測(cè)到的每個(gè)測(cè)試，如果?ignoreFailures?值為 false，并且有測(cè)試不通過(guò)，那它就會(huì)停止繼續(xù)構(gòu)建。ignoreFailures?的默認(rèn)值為 false。?
The task has an?ignoreFailures?property to control the behavior when tests fail. Test always executes every test that it detects. It stops the build afterwards if?ignoreFailures?is false and there are failing tests. The default value of?ignoreFailures?is false.

testLogging?屬性可以配置哪些測(cè)試事件需要記錄，并且使用什么樣的日志級(jí)別。默認(rèn)情況下，對(duì)于每個(gè)失敗的測(cè)試都只會(huì)打印一個(gè)簡(jiǎn)潔的消息。請(qǐng)參閱?TestLoggingContainer，查看如何把測(cè)試日志調(diào)整為你的偏好設(shè)置。?
The?testLogging?property allows to configure which test events are going to be logged and at which detail level. By default, a concise message will be logged for every failed test. See?TestLoggingContainer?for how to tune test logging to your preferences.

23.12.2.?調(diào)試

23.12.2.?Debugging

test 任務(wù)提供了一個(gè)?Test.getDebug()?屬性，可以設(shè)置為啟動(dòng)，使 JVM 在執(zhí)行測(cè)試之前等待調(diào)試器連接到它的 5005 端口上。?
The test task provides a?Test.getDebug()?property that can be set to launch to make the JVM wait for a debugger to attach to port 5005 before proceeding with test execution.

這也可以在調(diào)用時(shí)通過(guò)?--debug-vm?任務(wù)選項(xiàng)進(jìn)行啟用。?
This can also be enabled at invocation time via the?--debug-jvm?task option.

23.12.3. 測(cè)試過(guò)濾

23.12.3.?Test filtering

從 Gradle 1.10 開(kāi)始，可以基于測(cè)試名稱模式，只包含特定測(cè)試。過(guò)濾是與測(cè)試類包含或排除所不同的一種機(jī)制，接下來(lái)的段落中將會(huì)對(duì)其詳細(xì)介紹（-Dtest.single，?test.include?和其他相關(guān)的）。后者基于文件，例如測(cè)試實(shí)現(xiàn)類的物理位置。文件級(jí)測(cè)試選擇不支持的許多有趣的場(chǎng)景，都可以用測(cè)試級(jí)過(guò)濾來(lái)實(shí)現(xiàn)。其中一些 Gradle 現(xiàn)在就可以處理，而有一些將在未來(lái)的版本中得到實(shí)現(xiàn)：?
Starting with Gradle 1.10, it is possible to include only specific tests, based on the test name pattern. Filtering is a different mechanism than test class inclusion / exclusion that will be described in the next few paragraphs (-Dtest.single,?test.include?and friends). The latter is based on files, e.g. the physical location of the test implementation class. File-level test selection does not support many interesting scenarios that are possible with test-level filtering. Some of them Gradle handles now and some will be satisfied in the future releases:

• 在指定的測(cè)試方法級(jí)別上過(guò)濾；執(zhí)行單個(gè)測(cè)試方法
  Filtering at the level of specific test methods; executing a single test method
• 基于自定義注解進(jìn)行過(guò)濾（以后實(shí)現(xiàn)）
  Filtering based on custom annotations (future)
• 基于測(cè)試層次結(jié)構(gòu)進(jìn)行過(guò)濾；執(zhí)行所有繼承了某一基類的測(cè)試（以后實(shí)現(xiàn)）
  Filtering based on test hierarchy; executing all tests that extend ceratain base class (future)
• 基于一些自定義的運(yùn)行時(shí)規(guī)則進(jìn)行過(guò)濾，例如某個(gè)系統(tǒng)屬性或一些靜態(tài)的特定值（以后實(shí)現(xiàn)）
  Filtering based on some custom runtime rule, e.g. particular value of a system property or some static state (future)

測(cè)試過(guò)濾功能具有以下的特征：?
Test filtering feature has following characteristic:

• 支持完整的限定類名稱或完整的限定方法名稱，例如“org.gradle.SomeTest”、“org.gradle.SomeTest.someMethod”
  Fully qualified class name or fully qualified method name is supported, e.g. "org.gradle.SomeTest", "org.gradle.SomeTest.someMethod"
• 通配符 “*” 支持匹配任何字符
  Wildcard '*' is supported for matching any characters
• 提供了“--tests”命令行選項(xiàng)，以方便設(shè)置測(cè)試過(guò)濾器。特別適用于傳統(tǒng)的“單一測(cè)試方法執(zhí)行”用例。當(dāng)使用該命令行選項(xiàng)時(shí)，構(gòu)建腳本中聲明的包含過(guò)濾器將被忽略。?
  Command line option "--tests" is provided to conveniently set the test filter. Especially useful for the classic 'single test method execution' use case. When the command line option is used, the inclusion filters declared in the build script are ignored.
• 鑒于特定測(cè)試框架 API 的限制，Gradle 會(huì)盡最大努力過(guò)濾測(cè)試。一些高級(jí)的、綜合的測(cè)試可能不完全符合過(guò)濾條件。但是，絕大多數(shù)測(cè)試和用例都應(yīng)該能被較好地處理。?
  Gradle tries best to filter the tests given limitations of particular test framework API. Some advanced, synthetic tests may not be fully compatible with filtering. However, vast majority of tests and use cases should be handled neatly.
• 測(cè)試過(guò)濾取代了基于文件的測(cè)試選擇。后者可能會(huì)在將來(lái)被完全取代。我們將會(huì)增加測(cè)試過(guò)濾 API 并添加更多類型的過(guò)濾器。?
  Test filtering supersedes the file-based test selection. The latter may be completely replaced in future. We will grow the the test filtering api and add more kinds of filters.

示例 23.11. 在構(gòu)建腳本中過(guò)濾測(cè)試 - Example?23.11.?Filtering tests in the build script

build.gradle

test {filter {//include specific method in any of the testsincludeTestsMatching "*UiCheck"//include all tests from packageincludeTestsMatching "org.gradle.internal.*"//include all integration testsincludeTestsMatching "*IntegTest"} }

有關(guān)更多的詳細(xì)信息和示例，請(qǐng)參閱?TestFilter?的文檔。?
For more details and examples please see the?TestFilter?reference.

使用命令行選項(xiàng)的一些示例：?
Some examples of using the command line option:

• gradle test --tests org.gradle.SomeTest.someSpecificFeature

• gradle test --tests *SomeTest.someSpecificFeature

• gradle test --tests *SomeSpecificTest

• gradle test --tests all.in.specific.package*

• gradle test --tests *IntegTest

• gradle test --tests *IntegTest*ui*

• gradle someTestTask --tests *UiTest someOtherTestTask --tests *WebTest*ui

23.12.4. 通過(guò)系統(tǒng)屬性執(zhí)行單個(gè)測(cè)試

23.12.4.?Single test execution via System Properties

如上所述，這種機(jī)制已經(jīng)被“測(cè)試過(guò)濾”所取代。

設(shè)置一個(gè)?taskName.single?=?testNamePattern?的系統(tǒng)屬性將會(huì)只執(zhí)行匹配指定的?testNamePattern?的測(cè)試。該?taskName?可以是完整的多項(xiàng)目路徑，如“:sub1:sub2:test”，或者僅是一個(gè)任務(wù)名稱。該?testNamePattern?將被用于形成“**/testNamePattern*.class”的包含模式。如果找不到這種模式的測(cè)試，那么將會(huì)拋出一個(gè)異常。這是為了避免你誤認(rèn)為測(cè)試通過(guò)。如果執(zhí)行多個(gè)子項(xiàng)目的測(cè)試，則該模式將應(yīng)用于每個(gè)子項(xiàng)目。如果找不到特定子項(xiàng)目的測(cè)試，則會(huì)引發(fā)異常。在這種情況下，你可以使用模式的路徑標(biāo)記法，以便模式僅應(yīng)用于特定子項(xiàng)目的測(cè)試任務(wù)?；蛘吣憧梢灾付ㄒ獔?zhí)行的任務(wù)的完整限定名稱。你還可以指定多個(gè)模式。示例：?
Setting a system property of?taskName.single?=?testNamePattern?will only execute tests that match the specified?testNamePattern. The?taskName?can be a full multi-project path like ":sub1:sub2:test" or just the task name. The?testNamePattern?will be used to form an include pattern of "**/testNamePattern*.class". If no tests with this pattern can be found an exception is thrown. This is to shield you from false security. If tests of more than one subproject are executed, the pattern is applied to each subproject. An exception is thrown if no tests can be found for a particular subproject. In such a case you can use the path notation of the pattern, so that the pattern is applied only to the test task of a specific subproject. Alternatively you can specify the fully qualified task name to be executed. You can also specify multiple patterns. Examples:

• gradle -Dtest.single=ThisUniquelyNamedTest test

• gradle -Dtest.single=a/b/ test

• gradle -DintegTest.single=*IntegrationTest integTest

• gradle -Dtest.single=:proj1:test:Customer build

• gradle -DintegTest.single=c/d/ :proj1:integTest

23.12.5. 測(cè)試檢測(cè)

23.12.5.?Test detection

Test?任務(wù)通過(guò)檢查編譯的測(cè)試類來(lái)檢測(cè)哪些類是測(cè)試類。默認(rèn)情況下，它會(huì)掃描所有?.class?文件。你可以設(shè)置自定義包含或排除哪些類，只有這些類才會(huì)被掃描。根據(jù)所使用的測(cè)試框架（JUnit 或 TestNG），會(huì)使用不同的標(biāo)準(zhǔn)進(jìn)行測(cè)試類的檢測(cè)。?
The?Test?task detects which classes are test classes by inspecting the compiled test classes. By default it scans all?.class?files. You can set custom includes / excludes, only those classes will be scanned. Depending on the test framework used (JUnit / TestNG) the test class detection uses different criteria.

當(dāng)使用 JUnit 時(shí)，我們掃描 JUnit 3 和 4 的測(cè)試類。如果符合以下任何標(biāo)準(zhǔn)，則該類將被視為 JUnit 測(cè)試類：?
When using JUnit, we scan for both JUnit 3 and 4 test classes. If any of the following criteria match, the class is considered to be a JUnit test class:

• 類或超類繼承自?TestCase?或?GroovyTestCase

  Class or a super class extends?TestCase?or?GroovyTestCase

• 類或超類使用了?@RunWith?注解

  Class or a super class is annotated with?@RunWith

• 類或超類含有一個(gè)帶?@Test?注解的方法

  Class or a super class contain a method annotated with?@Test

當(dāng)使用 TestNG 時(shí)，我們掃描帶有?@Test?注解的方法。?
When using TestNG, we scan for methods annotated with?@Test.

請(qǐng)注意，抽象類不會(huì)被執(zhí)行。 Gradle 還將掃描測(cè)試類路徑中的 jar 文件的繼承樹(shù)。?
Note that abstract classes are not executed. Gradle also scan up the inheritance tree into jar files on the test classpath.

如果您不想使用測(cè)試類檢測(cè)，則可以通過(guò)設(shè)置?scanForTestClasses?為 false 來(lái)禁用它。這將使測(cè)試任務(wù)僅使用包含或排除來(lái)查找測(cè)試類。如果?scanForTestClasses?被禁用，并且沒(méi)有指定包含或排除模式，則使用相應(yīng)的默認(rèn)值。對(duì)于包含的默認(rèn)值是?“**/*Tests.class”，“**/*Test.class”，而排除的默認(rèn)值是?“**/Abstract*.class”。?
In case you don't want to use the test class detection, you can disable it by setting?scanForTestClasses?to false. This will make the test task only use the includes / excludes to find test classes. If?scanForTestClasses?is disabled and no include or exclude patterns are specified, the respective defaults are used. For include this is?"**/*Tests.class", "**/*Test.class"?and the for exclude it is?"**/Abstract*.class".

23.12.6. 測(cè)試分組

23.12.6.?Test grouping

JUnit 和 TestNG 支持復(fù)雜的測(cè)試方法分組。?
JUnit and TestNG allows sophisticated groupings of test methods.

為對(duì) JUnit 的測(cè)試類和方法進(jìn)行分組，JUnit 4.8 引入了類別的概念。?^[9]test?任務(wù)允許指定要包含和排除的 JUnit 類別。?
For grouping JUnit test classes and methods JUnit 4.8 introduces the concept of categories.?^[9]?The?test?task allows the specification of the JUnit categories you want to include and exclude.

示例 23.12. JUnit 類別 - Example?23.12.?JUnit Categories

build.gradle

test {useJUnit {includeCategories 'org.gradle.junit.CategoryA'excludeCategories 'org.gradle.junit.CategoryB'} }

TestNG 框架則有一個(gè)非常相似的概念。在 TestNG 中，你可以指定不同的測(cè)試組。?^[10]你可以在測(cè)試任務(wù)中配置應(yīng)該包含在測(cè)試執(zhí)行中或從測(cè)試執(zhí)行中排除的測(cè)試組。?
The TestNG framework has a quite similar concept. In TestNG you can specify different test groups.?^[10]?The test groups that should be included or excluded from the test execution can be configured in the test task.

示例 23.13. 對(duì) TestNG 測(cè)試分組 - Example?23.13.?Grouping TestNG tests

build.gradle

test {useTestNG {excludeGroups 'integrationTests'includeGroups 'unitTests'} }

23.12.7. 測(cè)試報(bào)告

23.12.7.?Test reporting

test?任務(wù)默認(rèn)情況下會(huì)生成以下結(jié)果。
The?Test?task generates the following results by default.

• 一個(gè) HTML 測(cè)試報(bào)告。

  An HTML test report.

• 與 Ant Junit report 任務(wù)兼容的 XML 格式的結(jié)果。許多工具都支持這一格式，比如 CI 服務(wù)器。

  The results in an XML format that is compatible with the Ant JUnit report task. This format is supported by many other tools, such as CI servers.

• 有效的二進(jìn)制格式的結(jié)果。該任務(wù)從這些二進(jìn)制結(jié)果生成其他結(jié)果。

  Results in an efficient binary format. The task generates the other results from these binary results.

還有一個(gè)獨(dú)立的?TestReport?任務(wù)類型，它可以從一個(gè)或多個(gè)?Test?任務(wù)實(shí)例生成的二進(jìn)制結(jié)果中生成 HTML 測(cè)試報(bào)告。要使用此任務(wù)類型，你需要定義一個(gè)?destinationDir?以及要包含在報(bào)告的測(cè)試結(jié)果。下面是一個(gè)從子項(xiàng)目的單元測(cè)試中生成一個(gè)組合報(bào)告的示例：?
There is also a stand-alone?TestReport?task type which can generate the HTML test report from the binary results generated by one or more?Test?task instances. To use this task type, you need to define a?destinationDir?and the test results to include in the report. Here is a sample which generates a combined report for the unit tests from subprojects:

示例 23.14. 為多個(gè)子項(xiàng)目創(chuàng)建一個(gè)單元測(cè)試報(bào)告 - Example?23.14.?Creating a unit test report for subprojects

build.gradle

subprojects {apply plugin: 'java'// Disable the test report for the individual test tasktest {reports.html.enabled = false} }task testReport(type: TestReport) {destinationDir = file("$buildDir/reports/allTests")// Include the results from the `test` task in all subprojectsreportOn subprojects*.test }

你應(yīng)該注意的是，TestReport?類型結(jié)合了多個(gè)測(cè)試任務(wù)的結(jié)果，并需要匯總各個(gè)測(cè)試類的結(jié)果。這意味著如果給定的測(cè)試類由多個(gè)測(cè)試任務(wù)執(zhí)行，那么測(cè)試報(bào)告將包括該類的執(zhí)行結(jié)果，但很難區(qū)分這個(gè)類的單獨(dú)執(zhí)行和它們的輸出。?
You should note that the?TestReport?type combines the results from multiple test tasks and needs to aggregate the results of individual test classes. This means that if a given test class is executed by multiple test tasks, then the test report will include executions of that class, but it can be hard to distinguish individual executions of that class and their output.

23.12.7.1. TestNG 參數(shù)化方法和報(bào)告

23.12.7.1.?TestNG parameterized methods and reporting

TestNG 支持參數(shù)化測(cè)試方法，允許使用不同的輸入多次執(zhí)行特定的測(cè)試方法。 Gradle 會(huì)在這個(gè)測(cè)試方法執(zhí)行的報(bào)告中包含參數(shù)值。?
TestNG supports?parameterizing test methods, allowing a particular test method to be executed multiple times with different inputs. Gradle includes the parameter values in its reporting of the test method execution.

給定一個(gè)帶有兩個(gè)參數(shù)，名為?aParameterizedTestMethod?的參數(shù)化測(cè)試方法，它將使用這個(gè)名稱進(jìn)行報(bào)告 ：aParameterizedTestMethod(toStringValueOfParam1, toStringValueOfParam2)。這使得在特定的迭代中，很容易識(shí)別參數(shù)值。?
Given a parameterized test method named?aParameterizedTestMethod?that takes two parameters, it will be reported with the name:?aParameterizedTestMethod(toStringValueOfParam1, toStringValueOfParam2). This makes identifying the parameter values for a particular iteration easy.

23.12.8. 約定值

23.12.8.?Convention values

表 23.14. Java 插件——測(cè)試屬性 - Table?23.14.?Java plugin - test properties

任務(wù)屬性 Task Property	類型 Type	默認(rèn)值 Default Value
testClassesDir	File	sourceSets.test.output.classesDir
classpath	FileCollection	sourceSets.test.runtimeClasspath
testResultsDir	File	testResultsDir
testReportDir	File	testReportDir
testSrcDirs	List<File>	sourceSets.test.java.srcDirs

23.13.?Jar

23.13.?Jar

jar?任務(wù)創(chuàng)建一個(gè)包含項(xiàng)目的類文件和資源的 JAR 文件。 JAR文件被聲明為在?archives?依賴配置中的一個(gè)構(gòu)件。這意味著這個(gè) JAR 文件在依賴它的項(xiàng)目的類路徑中可用。如果將項(xiàng)目上傳到倉(cāng)庫(kù)中，則這個(gè) JAR 文件會(huì)被聲明為依賴描述符的一部分。關(guān)于如何處理檔案，可以在《第 16.8 節(jié)，“創(chuàng)建檔案”》中了解，而構(gòu)件配置則可參考《第五十一章，發(fā)布構(gòu)件》。?
The?jar?task creates a JAR file containing the class files and resources of the project. The JAR file is declared as an artifact in the?archives?dependency configuration. This means that the JAR is available in the classpath of a dependent project. If you upload your project into a repository, this JAR is declared as part of the dependency descriptor. You can learn more about how to work with archives in?Section?16.8, “Creating archives”?and artifact configurations in?Chapter?51,?Publishing artifacts.

23.13.1.?Manifest

23.13.1.?Manifest

每個(gè) jar 或 war 對(duì)象都有一個(gè)?manifest?屬性，它是一個(gè)單獨(dú)的?Manifest?屬性。當(dāng)生成檔案時(shí)，相應(yīng)的?MANIFEST.MF?文件會(huì)被寫(xiě)入存檔。?
Each jar or war object has a?manifest?property with a separate instance of?Manifest. When the archive is generated, a corresponding?MANIFEST.MF?file is written into the archive.

示例 7.5. 自定義的 MANIFEST.MF - Example?23.15.?Customization of MANIFEST.MF

build.gradle

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

你可以創(chuàng)建一個(gè)獨(dú)立的?Manifest?實(shí)例。例如，可以用它來(lái)在 jar 之間共享清單信息。?
You can create stand alone instances of a?Manifest. You can use that for example, to share manifest information between jars.

示例 23.16. 創(chuàng)建一個(gè)清單對(duì)象。 - Example?23.16.?Creating a manifest object.

build.gradle

ext.sharedManifest = manifest {attributes("Implementation-Title": "Gradle", "Implementation-Version": version) } task fooJar(type: Jar) {manifest = project.manifest {from sharedManifest} }

你可以把其他清單合并到任意的一個(gè)?Manifest?對(duì)象。其他清單可以用文件路徑來(lái)描述，或者像上面的例子那樣，通過(guò)引用另一個(gè)?Manifest?對(duì)象來(lái)描述。?
You can merge other manifests into any?Manifest?object. The other manifests might be either described by a file path or, like in the example above, by a reference to another?Manifest?object.

示例 23.17. 指定檔案的單獨(dú) MANIFEST.MF - Example?23.17.?Separate MANIFEST.MF for a particular archive

build.gradle

task barJar(type: Jar) {manifest {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()}}}} }

Manifest 會(huì)根據(jù)在?from?語(yǔ)句中所聲明的順序進(jìn)行合并。如果基本的清單和合并清單都定義了同一個(gè)鍵的值，那么默認(rèn)情況下會(huì)采用要合并的清單的值。你可以通過(guò)添加?eachEntry?來(lái)完全自定義結(jié)果清單的每一個(gè)實(shí)體的合并行為，它讓你可以訪問(wèn)?ManifestMergeDetails?實(shí)例。合并不會(huì)立即由 from 語(yǔ)句觸發(fā)。它是惰性執(zhí)行的，在生成 jar 或者是通過(guò)調(diào)用?writeTo?或?effectiveManifest?的時(shí)候完成。
Manifest are merged in the order they are declared by the?from?statement. If the based manifest and the merged manifest both define values for the same key, the merged manifest wins by default. You can fully customize the merge behavior by adding?eachEntry?actions in which you have access to a?ManifestMergeDetails?instance for each entry of the resulting manifest. The merge is not immediately triggered by the from statement. It is done lazily, either when generating the jar, or by calling?writeTo?or?effectiveManifest

你可以很輕松地把一個(gè)清單寫(xiě)入磁盤(pán)。?
You can easily write a manifest to disk.

示例 23.18. 指定檔案的單獨(dú) MANIFEST.MF - Example?23.18.?Separate MANIFEST.MF for a particular archive

build.gradle

jar.manifest.writeTo("$buildDir/mymanifest.mf")

23.14. 上傳

23.14.?Uploading

關(guān)于如何上傳檔案，將在《第五十一章，發(fā)布構(gòu)件》中描述。?
How to upload your archives is described in?Chapter?51,?Publishing artifacts.

---

[9]?JUnit wiki 包含了有關(guān)如何使用 JUnit 類別的詳細(xì)說(shuō)明：?https://github.com/junit-team/junit/wiki/Categories。?
[9]?The JUnit wiki contains a detailed description on how to work with JUnit categories:?https://github.com/junit-team/junit/wiki/Categories.

[10]?TestNG 文檔包含了有關(guān)測(cè)試組的更多詳細(xì)信息：http://testng.org/doc/documentation-main.html#test-groups。?
[10]?The TestNG documentation contains more details about test groups:?http://testng.org/doc/documentation-main.html#test-groups.

總結(jié)

以上是生活随笔為你收集整理的Gradle 2.0 用户指南翻译——第二十三章. Java 插件的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。