翻譯項目請關注Github上的地址：
https://github.com/msdx/gradledoc
本文翻譯所在分支：
https://github.com/msdx/gradledoc/tree/2.0 。
在線瀏覽地址：
http://gradledoc.qiniudn.com/2.0/userguide/userguide.html 。
另外，Android 手機用戶可通過我寫的一個程序瀏覽文檔，帶緩存功能的，目前0.6開發中版本兼容 Android 2.3以上系統，項目地址如下：
https://github.com/msdx/gradle-doc-apk
翻譯不易，轉載請注明本文在CSDN博客上的出處：
https://blog.csdn.net/maosidiaoxian/article/details/80140234

關于我對Gradle的翻譯，以Github上的項目及http://gradledoc.qiniudn.com 上的文檔為準。如發現翻譯有誤的地方，將首先在以上兩個地方更新。因時間精力問題，博客中發表的譯文基本不會同步修改。

第二十三章. Java 插件

Chapter?23.?The Java Plugin

Java 插件向項目添加 Java 編譯、測試和捆綁的功能。它是其他許多 Gradle 插件的基礎。?
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 插件，請在構建腳本中加入以下內容：
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 插件引入了一個源集的概念。源集只是一組源文件，它們被一起編譯和執行。這些源文件可能包含 Java 源文件和資源文件，有些其他插件可以將 Groovy 和 Scala 源文件包含在源集中。一個源集有一個相關聯的編譯類路徑和運行時類路徑。?
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.

源集的一個用途是，將源文件進行邏輯上的分組，以描述它們的目的。例如，你可以使用一個源集來定義一個集成測試套件，也可以使用單獨的源集來定義項目的 API 和實現類。?
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 插件定義了兩個標準源集，分別是?main?和?test。main?源集包含生產源代碼，將其編譯并組裝到 JAR 文件中。test?源集則包含了單元測試源代碼，它們將被編譯并使用 JUnit 或 TestNG 來執行。?
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. 任務

23.3.?Tasks

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

表 23.1. Java 插件——任務 - Table?23.1.?Java plugin - tasks

任務名稱 Task name	依賴于 Depends on	類型 Type	描述 Description
CompileJava	所有產生編譯類路徑的任務，也包括了?jar?任務，因為項目依賴被包含在?compile?配置中。? All tasks which produce the compile classpath. This includes the?jar?task for project dependencies included in the?compile?configuration.	JavaCompile	使用 javac 編譯 Java 生產源文件。 Compiles production Java source files using javac.
processResources	-	Copy	把生產資源文件復制到生產類目錄中。 Copies production resources into the production classes directory.
classes	compileJava?和?processResources。有些插件會添加其他的編譯任務。? compileJava?and?processResources. Some plugins add additional compilation tasks.	Task	組裝生產類目錄。 Assembles the production classes directory.
compileTestJava	compile?任務，以及所有能產生測試編譯類路徑的任務。? compile, plus all tasks which produce the test compile classpath.	JavaCompile	使用 javac 編譯 Java 測試源文件。 Compiles test Java source files using javac.
processTestResources	-	Copy	把測試資源文件拷貝到測試類目錄中。 Copies test resources into the test classes directory.
testClasses	compileTestJava?和?processTestResources。有些插件會添加其他的測試編譯任務。? compileTestJava?and?processTestResources. Some plugins add additional test compilation tasks.	Task	組裝測試類目錄。 Assembles the test classes directory.
jar	compile	Jar	組裝 JAR 文件 Assembles the JAR file
javadoc	compile	Javadoc	使用 Javadoc 生成生產的 Java 源代碼的API文檔? Generates API documentation for the production Java source, using Javadoc
test	compile，?compileTest，以及所有產生測試運行時類路徑的任務。? compile,?compileTest, plus all tasks which produce the test runtime classpath.	Test	使用 JUnit 或 TestNG 運行單元測試。 Runs the unit tests using JUnit or TestNG.
uploadArchives	產生在?archives?中所配置的工件的任務，包括?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	刪除項目的構建目錄。 Deletes the project build directory.
cleanTaskName	-	Delete	刪除指定任務生成的輸出文件。例如?cleanJar?將刪除由該?jar?任務創建的 JAR 文件，而?cleanTest?將刪除由該?test?任務創建的測試結果。? 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.

對于你添加到項目中的每一個源集，Java 插件將添加以下的編譯任務：
For each source set you add to the project, the Java plugin adds the following compilation tasks:

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

任務名稱 Task name	依賴于 Depends on	類型 Type	描述 Description
compileSourceSetJava	所有產生源集編譯類路徑的任務。? 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	將給定源集的資源文件復制到類目錄中。 Copies the given source set's resources into the classes directory.
sourceSetClasses	compileSourceSetJava?和?processSourceSetResources。有些插件還為源集添加了其他的編譯任務。? compileSourceSetJava?and?processSourceSetResources. Some plugins add additional compilation tasks for the source set.	Task	組裝給定源集的類目錄。 Assembles the given source set's classes directory.

Java 插件還增加了大量構成項目生命周期的任務：
The Java plugin also adds a number of tasks which form a lifecycle for the project:

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

任務名稱 Task name	依賴于 Depends on	類型 Type	描述 Description
assemble	項目中的所有歸檔任務，包括?jar。有些插件會向項目添加另外的歸檔任務。? All archive tasks in the project, including?jar. Some plugins add additional archive tasks to the project.	Task	組裝項目中所有的歸檔文件。 Assembles all the archives in the project.
check	項目中的所有驗證任務，包括?test。有些插件會向項目添加另外的驗證任務。? All verification tasks in the project, including?test. Some plugins add additional verification tasks to the project.	Task	執行項目中所有的驗證任務。 Performs all verification tasks in the project.
build	check?和?assemble? check?and?assemble	Task	執行完整的項目構建。 Performs a full build of the project.
buildNeeded	build?任務，以及在?testRuntime?配置的所有項目庫依賴項的?build?任務。? build?and?build?tasks in all project lib dependencies of the?testRuntimeconfiguration.	Task	執行項目本身及它所依賴的其他所有項目的完整構建。 Performs a full build of the project and all projects it depends on.
buildDependents	build?任務，以及在?testRuntime?配置中對此項目有庫依賴的所有項目的?build?任務。? build?and?build?tasks in all projects with a project lib dependency on this project in a?testRuntime?configuration.	Task	執行項目本身及依賴它的其他所有項目的完整構建。 Performs a full build of the project and all projects which depend on it.
buildConfigurationName	生成?ConfigurationName?配置里的工件的任務。? The tasks which produce the artifacts in configuration?ConfigurationName.	Task	組裝指定配置的工件。該任務由 Base 插件添加，并由 Java 插件隱式應用。? 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?配置中的工件的任務。? The tasks which uploads the artifacts in configuration?ConfigurationName.	Upload	以指定的配置組裝并上傳工件。該任務由 Base 插件添加，并由 Java 插件隱式應用。? 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.

下圖顯示了這些任務之間的關系。
The following diagram shows the relationships between these tasks.

圖 23.1. Java 插件——任務 - Figure?23.1.?Java plugin - tasks

23.4. 項目布局

23.4.?Project layout

Java 插件會假定如下所示的項目布局。這些目錄都不需要一定的存在在，或是里面有什么內容。 Java插件不管發現什么都將會進行編譯，并處理缺失的任何內容。?
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 插件——默認項目布局 - Table?23.4.?Java plugin - default project layout

目錄 Directory	意義 Meaning
src/main/java	Java 生產源代碼 Production Java source
src/main/resources	生產資源 Production resources
src/test/java	Java 測試源代碼 Test Java source
src/test/resources	測試資源 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. 更改項目布局

23.4.1.?Changing the project layout

你可以通過配置適當的源集來配置項目的布局，這點將在下面的章節中詳細討論。以下是一個簡單的例子，展示如何改變 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 插件向項目添加了一些依賴配置，如下表所示。它將這些配置指定一些任務，如?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	在哪些任務中使用 Used by tasks	意義 Meaning
compile	-	CompileJava	編譯時依賴 Compile time dependencies
runtime	compile	-	運行時依賴 Runtime dependencies
testCompile	compile	compileTestJava	用于編譯測試代碼的其他依賴 Additional dependencies for compiling tests.
testRuntime	runtime, testCompile	test	只用于運行測試的其他依賴 Additional dependencies for running tests only.
archives	-	uploadArchives	由本項目產生的工件（如 jar 包）。 Artifacts (e.g. jars) produced by this project.
default	runtime	-	依賴于本項目的另一個項目所使用的默認配置。包含此項目運行時所需的工件和依賴。? 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

對于你添加到項目中的每個源集，Java 插件都會添加以下的依賴配置：
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	在哪些任務中使用 Used by tasks	意義 Meaning
sourceSetCompile	-	compileSourceSetJava	給定源集的編譯時依賴 Compile time dependencies for the given source set
sourceSetRuntime	sourceSetCompile	-	給定源集的運行時依賴 Runtime time dependencies for the given source set

23.6. 約定屬性

23.6.?Convention properties

Java 插件向項目添加了許多約定屬性，如下表所示。你可以在構建腳本中使用這些屬性，就像它們是 project 對象里的屬性一樣（見《第 21.3 節，“約定”》）。?
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	默認值 Default value	描述 Description
reportsDirName	String	reports	相對于構建目錄，生成報告的目錄的名稱。? The name of the directory to generate reports into, relative to the build directory.
reportsDir	File?（只讀）? File?(read-only)	buildDir/reportsDirName	要生成報告的目錄。? The directory to generate reports into.
testResultsDirName	String	test-results	相對于構建目錄，生成測試結果.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	生成測試結果.xml 文件的目錄。? The directory to generate test result .xml files into.
testReportDirName	String	tests	相對于報告目錄，生成測試報告的目錄的名稱。? The name of the directory to generate the test report into, relative to the reports directory.
testReportDir	File?（只讀）? File?(read-only)	reportsDir/testReportDirName	生成測試報告的目錄。? The directory to generate the test report into.
libsDirName	String	libs	相對于構建目錄，生成庫的目錄的名稱。? The name of the directory to generate libraries into, relative to the build directory.
libsDir	File?（只讀）? File?(read-only)	buildDir/libsDirName	要生成庫的目錄。? The directory to generate libraries into.
distsDirName	String	distributions	相對于構建目錄的目錄名稱，該目錄用于生成分發的文件。? The name of the directory to generate distributions into, relative to the build directory.
distsDir	File?（只讀）? File?(read-only)	buildDir/distsDirName	生成分發文件的目錄。? The directory to generate distributions into.
docsDirName	String	docs	相對于構建目錄的目錄名稱，該目錄用于生成文檔。? 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	相對于構建目錄的目錄名稱，該目錄用于緩存源代碼的依賴信息。? 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	默認值 Default value	描述 Description
sourceSets	SourceSetContainer?（只讀） SourceSetContainer?(read-only)	不為 null Not null	包含項目的源集。 Contains the project's source sets.
sourceCompatibility	JavaVersion。也可以使用字符串或數字來設置，如?'1.5'?或?1.5。? JavaVersion. Can also set using a String or a Number, e.g.?'1.5'?or?1.5.	當前所使用的 JVM 的值 Value of the current used JVM	當編譯 Java 源代碼時所使用的 Java 版本兼容性。 Java version compatibility to use when compiling Java source.
targetCompatibility	JavaVersion。也可以使用字符串或數字來設置，如?'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	一個空的清單 an empty manifest	包含在所有 JAR 文件中的清單。 The manifest to include in all JAR files.

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

23.7.?使用源集

23.7.?Working with source sets

你可以使用?sourceSets?屬性訪問項目的源集。這是項目源集的容器，它的類型是?SourceSetContainer。除此之外，還有一個?sourceSets{}?腳本塊，可以傳入一個閉包來配置源集容器。源集容器的使用方式與其他的容器幾乎一樣，例如?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. 訪問源集 - 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 }

要配置一個現有的源集，你只需要使用上面的其中一種訪問方法來設置源集的屬性。這些屬性將在下文中進行介紹。以下是配置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 文檔中找到更多有關?SourceSet?的詳細信息。?
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	默認值 Default value	描述 Description
name	String?（只讀）? String?(read-only)	不為 null? Not null	用來確定一個源集的源集名稱。? The name of the source set, used to identify it.
output	SourceSetOutput?（只讀）? SourceSetOutput?(read-only)	不為 null? Not null	源集的輸出文件，包含其編譯過的類和資源。? 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.	編譯該源集的源文件時使用的類路徑。? The classpath to use when compiling the source files of this source set.
runtimeClasspath	FileCollection	output?+?runtimeSourceSet?配置。? output?+?runtimeSourceSetconfiguration.	執行此源集的類時使用的類路徑。? 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 節，“指定一組輸入文件”》中所講到的任何一種方法來設置。? 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 插件）會從此集合中排除其他類型的文件。? 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 節，“指定一組輸入文件”》中所講到的任何一種方法來設置。? 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 插件，會將其他 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 插件）會將其他源文件添加到此集合中。? 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

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

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

build.gradle

sourceSets {intTest }

當你定義一個新的源集時，Java 插件會為該源集添加一些依賴配置，如表 23.6，“Java 插件——源集依賴性配置”所示。你可以使用這些配置來定義源集的編譯和運行時依賴。?
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 插件還添加了大量的任務用于組裝源集的類，如表 23.2，“Java 插件——源集任務”所示。例如，對于一個名為?intTest?的源集，你可以通過運行gradle intTestClasses來編譯 int 測試類。?
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?的輸出結果
Output of?gradle intTestClasses

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

23.7.3. 一些源集的范例

23.7.3.?Some source set examples

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

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

build.gradle

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

為一個源集生成 Javadoc：
Generating Javadoc for a source set:

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

build.gradle

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

添加測試套件以運行源集里的測試
Adding a test suite to run the tests in a source set:

示例 23.10. 運行源集里的測試 - 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?任務是?Javadoc?的一個實例。它支持核心 javadoc 的參數選項，以及在 Javadoc 可執行文件的參考文檔中描述的標準 doclet 參數選項。對于所支持的 Javadoc 參數選項的完整列表，請參考下面的類的 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

任務屬性 Task Property	類型 Type	默認值 Default Value
classpath	FileCollection	sourceSets.main.output + sourceSets.main.compileClasspath
source	FileTree?？梢允褂谩兜?16.5 節，“指定一組輸入文件”》中所講到的任何一種方法來設置。 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	項目的名稱和版本 The name and version of the project

23.9.?Clean

23.9.?Clean

clean?任務是?Delete?的一個實例。它只是刪除由?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

任務屬性 Task Property	類型 Type	默認值 Default Value
dir	File	buildDir

23.10.?Resources

23.10.?Resources

Java 插件使用?Copy?任務進行資源的處理，它為項目中的每個源集添加一個實例。你可以在《第 16.6 節，“復制文件”》找到更多關于復制任務的信息。?
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

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

23.11.?CompileJava

23.11.?CompileJava

Java 插件為項目里的每一個源集添加一個?JavaCompile?實例。一些最常見的配置選項如下所示。?
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

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

默認情況下，Java 編譯器在 Gradle 進程中運行。將?options.fork?設置為?true?將使得在一個單獨的進程中進行編譯。在Ant javac 任務的情況中，意味著每個編譯任務都會 fork 一個新進程，這樣就會使編譯變慢。相反，Gradle 的直接編譯器集成（見上文）將盡可能地重用相同的編譯器進程。在這兩種情況下，使用?options.forkOptions?指定的所有 fork 選項都將得到重視。?
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?任務是?Test?的一個實例。它會自動檢測并執行?test?源集中的所有單元測試。測試執行完成后，它還會生成一個報告。它同時支持 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. 測試執行

23.12.1.?Test execution

測試在單獨的 JVM 進程中執行，與主構建進程隔離。Test?任務的 API 允許你對這種情況進行一些控制。?
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.

有很多屬性可以控制測試進程的啟動，包括系統屬性、JVM 參數以及要使用的Java 可執行文件。?
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.

你可以指定是否要并行執行測試。Gradle 通過同時運行多個測試進程來提供并行測試的執行。每個測試進程一次只執行一個測試，所以通常不需要為測試做任何特殊的配置就可以利用這一點。maxParallelForks?屬性指定了在給定的任何時間可以運行的最大測試進程數。默認值為1，即不并行執行測試。?
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.

測試進程程會將?org.gradle.test.worker?系統屬性設置為該測試進程的一個唯一標識符，這個標識符可以用于文件名稱或其他資源標識符。?
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.

你可以指定在執行了一定數量的測試類之后，重新啟動測試進程。這是一個很有用的替代方案，可以讓你的測試進程有非常大的堆內存。forkEvery?屬性指定了要在測試進程中執行的最大測試類的數量。默認是在每個測試進程中執行的測試數量不限。
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.

該任務有一個?ignoreFailures?屬性，用于控制測試失敗時的行為。測試任務始終執行它檢測到的每個測試，如果?ignoreFailures?值為 false，并且有測試不通過，那它就會停止繼續構建。ignoreFailures?的默認值為 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?屬性可以配置哪些測試事件需要記錄，并且使用什么樣的日志級別。默認情況下，對于每個失敗的測試都只會打印一個簡潔的消息。請參閱?TestLoggingContainer，查看如何把測試日志調整為你的偏好設置。?
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.?調試

23.12.2.?Debugging

test 任務提供了一個?Test.getDebug()?屬性，可以設置為啟動，使 JVM 在執行測試之前等待調試器連接到它的 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.

這也可以在調用時通過?--debug-vm?任務選項進行啟用。?
This can also be enabled at invocation time via the?--debug-jvm?task option.

23.12.3. 測試過濾

23.12.3.?Test filtering

從 Gradle 1.10 開始，可以基于測試名稱模式，只包含特定測試。過濾是與測試類包含或排除所不同的一種機制，接下來的段落中將會對其詳細介紹（-Dtest.single，?test.include?和其他相關的）。后者基于文件，例如測試實現類的物理位置。文件級測試選擇不支持的許多有趣的場景，都可以用測試級過濾來實現。其中一些 Gradle 現在就可以處理，而有一些將在未來的版本中得到實現：?
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:

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

測試過濾功能具有以下的特征：?
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”命令行選項，以方便設置測試過濾器。特別適用于傳統的“單一測試方法執行”用例。當使用該命令行選項時，構建腳本中聲明的包含過濾器將被忽略。?
  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.
• 鑒于特定測試框架 API 的限制，Gradle 會盡最大努力過濾測試。一些高級的、綜合的測試可能不完全符合過濾條件。但是，絕大多數測試和用例都應該能被較好地處理。?
  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.
• 測試過濾取代了基于文件的測試選擇。后者可能會在將來被完全取代。我們將會增加測試過濾 API 并添加更多類型的過濾器。?
  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. 在構建腳本中過濾測試 - 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"} }

有關更多的詳細信息和示例，請參閱?TestFilter?的文檔。?
For more details and examples please see the?TestFilter?reference.

使用命令行選項的一些示例：?
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. 通過系統屬性執行單個測試

23.12.4.?Single test execution via System Properties

如上所述，這種機制已經被“測試過濾”所取代。

設置一個?taskName.single?=?testNamePattern?的系統屬性將會只執行匹配指定的?testNamePattern?的測試。該?taskName?可以是完整的多項目路徑，如“:sub1:sub2:test”，或者僅是一個任務名稱。該?testNamePattern?將被用于形成“**/testNamePattern*.class”的包含模式。如果找不到這種模式的測試，那么將會拋出一個異常。這是為了避免你誤認為測試通過。如果執行多個子項目的測試，則該模式將應用于每個子項目。如果找不到特定子項目的測試，則會引發異常。在這種情況下，你可以使用模式的路徑標記法，以便模式僅應用于特定子項目的測試任務?；蛘吣憧梢灾付ㄒ獔绦械娜蝿盏耐暾薅Q。你還可以指定多個模式。示例：?
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. 測試檢測

23.12.5.?Test detection

Test?任務通過檢查編譯的測試類來檢測哪些類是測試類。默認情況下，它會掃描所有?.class?文件。你可以設置自定義包含或排除哪些類，只有這些類才會被掃描。根據所使用的測試框架（JUnit 或 TestNG），會使用不同的標準進行測試類的檢測。?
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.

當使用 JUnit 時，我們掃描 JUnit 3 和 4 的測試類。如果符合以下任何標準，則該類將被視為 JUnit 測試類：?
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

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

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

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

請注意，抽象類不會被執行。 Gradle 還將掃描測試類路徑中的 jar 文件的繼承樹。?
Note that abstract classes are not executed. Gradle also scan up the inheritance tree into jar files on the test classpath.

如果您不想使用測試類檢測，則可以通過設置?scanForTestClasses?為 false 來禁用它。這將使測試任務僅使用包含或排除來查找測試類。如果?scanForTestClasses?被禁用，并且沒有指定包含或排除模式，則使用相應的默認值。對于包含的默認值是?“**/*Tests.class”，“**/*Test.class”，而排除的默認值是?“**/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. 測試分組

23.12.6.?Test grouping

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

為對 JUnit 的測試類和方法進行分組，JUnit 4.8 引入了類別的概念。?^[9]test?任務允許指定要包含和排除的 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 框架則有一個非常相似的概念。在 TestNG 中，你可以指定不同的測試組。?^[10]你可以在測試任務中配置應該包含在測試執行中或從測試執行中排除的測試組。?
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. 對 TestNG 測試分組 - Example?23.13.?Grouping TestNG tests

build.gradle

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

23.12.7. 測試報告

23.12.7.?Test reporting

test?任務默認情況下會生成以下結果。
The?Test?task generates the following results by default.

• 一個 HTML 測試報告。

  An HTML test report.

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

  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.

• 有效的二進制格式的結果。該任務從這些二進制結果生成其他結果。

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

還有一個獨立的?TestReport?任務類型，它可以從一個或多個?Test?任務實例生成的二進制結果中生成 HTML 測試報告。要使用此任務類型，你需要定義一個?destinationDir?以及要包含在報告的測試結果。下面是一個從子項目的單元測試中生成一個組合報告的示例：?
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. 為多個子項目創建一個單元測試報告 - 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 }

你應該注意的是，TestReport?類型結合了多個測試任務的結果，并需要匯總各個測試類的結果。這意味著如果給定的測試類由多個測試任務執行，那么測試報告將包括該類的執行結果，但很難區分這個類的單獨執行和它們的輸出。?
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 參數化方法和報告

23.12.7.1.?TestNG parameterized methods and reporting

TestNG 支持參數化測試方法，允許使用不同的輸入多次執行特定的測試方法。 Gradle 會在這個測試方法執行的報告中包含參數值。?
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.

給定一個帶有兩個參數，名為?aParameterizedTestMethod?的參數化測試方法，它將使用這個名稱進行報告 ：aParameterizedTestMethod(toStringValueOfParam1, toStringValueOfParam2)。這使得在特定的迭代中，很容易識別參數值。?
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 插件——測試屬性 - Table?23.14.?Java plugin - test properties

任務屬性 Task Property	類型 Type	默認值 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?任務創建一個包含項目的類文件和資源的 JAR 文件。 JAR文件被聲明為在?archives?依賴配置中的一個構件。這意味著這個 JAR 文件在依賴它的項目的類路徑中可用。如果將項目上傳到倉庫中，則這個 JAR 文件會被聲明為依賴描述符的一部分。關于如何處理檔案，可以在《第 16.8 節，“創建檔案”》中了解，而構件配置則可參考《第五十一章，發布構件》。?
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

每個 jar 或 war 對象都有一個?manifest?屬性，它是一個單獨的?Manifest?屬性。當生成檔案時，相應的?MANIFEST.MF?文件會被寫入存檔。?
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)} }

你可以創建一個獨立的?Manifest?實例。例如，可以用它來在 jar 之間共享清單信息。?
You can create stand alone instances of a?Manifest. You can use that for example, to share manifest information between jars.

示例 23.16. 創建一個清單對象。 - 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} }

你可以把其他清單合并到任意的一個?Manifest?對象。其他清單可以用文件路徑來描述，或者像上面的例子那樣，通過引用另一個?Manifest?對象來描述。?
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. 指定檔案的單獨 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 會根據在?from?語句中所聲明的順序進行合并。如果基本的清單和合并清單都定義了同一個鍵的值，那么默認情況下會采用要合并的清單的值。你可以通過添加?eachEntry?來完全自定義結果清單的每一個實體的合并行為，它讓你可以訪問?ManifestMergeDetails?實例。合并不會立即由 from 語句觸發。它是惰性執行的，在生成 jar 或者是通過調用?writeTo?或?effectiveManifest?的時候完成。
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

你可以很輕松地把一個清單寫入磁盤。?
You can easily write a manifest to disk.

示例 23.18. 指定檔案的單獨 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

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

---

[9]?JUnit wiki 包含了有關如何使用 JUnit 類別的詳細說明：?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 文檔包含了有關測試組的更多詳細信息：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.

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。