Japanese translation of Chapter 47. Java Quickstart on the official gradle page.
Chapter 47. Java Quickstart
As we've seen, Gradle is a generic build tool. Almost everything the user wants to implement can be built with a build script. However, you need to add code to your build script to run the build.
Most Java projects are basically similar. Compile Java source files, run unit tests, You need to create a JAR file that contains the classes. If you no longer need to code the above process in all your projects That would be nice. Fortunately, Gradle users don't have to code the above process. Gradle solves this problem by using a plugin. Plugins extend to allow you to configure your project in some way, Add useful preset tasks. Gradle comes with a number of plugins, so You can easily create it yourself and share it with others. One such plugin is the Java plugin. This plugin compiles the project's Java source code, runs unit tests, and Add some tasks to generate the JAR file.
Java plugins are convention-based. Plugins are the location of Java source files, etc. Defines default values for various aspects of the project. As long as you follow the conventions in your project, you don't have to make major changes to your build script You can run the build. If you do not want to follow the terms, or if you cannot follow the terms You can customize the project. In fact, Java project support is implemented as a plugin, so You can build Java projects without using plugins.
For Java plugins, dependency management, and multi-project builds We'll cover many examples in more detail in later chapters. In this chapter, to build a Java project I would like to provide the first idea of how to use Java plugins.
Let's look at a simple example. To use the Java plug-in, add the following line to your build file:
build.gradle
apply plugin: 'java'
Note: The code in this example is from Gradle's'-all' distribution. It is described in samples / java / quickstart.
This is all you need to define a Java project. By describing the above, the Java plugin will be applied to the project, Some tasks are added to the project.
** Tasks that can be performed **
You can use gradle tasks to list the tasks in your project. This will show you the tasks that the Java plug-in has added to your project.
Gradle puts the production source code under src / main / java, Try to find the test source code under src / test / java. In addition, all files under src / main / resources are included as resources in the JAR file, The files under src / test / resources are included in the classpath used to run the test. All output files are created under the build directory The JAR file is stored in the build / libs directory.
Java plugins add a large number of tasks to your project. However, only a handful of tasks are required to build a project. The most commonly used task is the build task, which does a complete build of your project. When you run gradle build, Gradle compiles and tests your code and Create a JAR file that contains the execution classes and resources.
** Example 47.2. Build Java project **
Output when running gradle build
> gradle build
:compileJava
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources
:testClasses
:test
:check
:build
BUILD SUCCESSFUL in 0s
6 actionable tasks: 6 executed
Here are some useful tasks.
clean
Delete the build directory and delete all the built files.
assemble
Compiles the code to generate a jar, but does not run unit tests. Other plugins add elements to this task. For example, if you use the War plugin This task also generates a WAR file for your project.
check
Compile and test your code. Other plugins add more checks to this task. For example, if you use the checkstyle plugin This task also runs Checkstyle on the source code.
Java projects usually have some dependencies on external JAR files. To reference these JAR files in your project You need to tell Gradle where to get the JAR file. In Gradle, artifacts such as JAR files are stored in the repository. Because the repository gets the project dependencies, Or to publish the deliverables of the project It can be used for or both. This example uses a public Maven repository.
** Example 47.3. Maven repository registration **
build.gradle
repositories {
mavenCentral()
}
Let's add some dependencies. Here, the production class has a compile-time dependency on commons collection, Declare that the test class depends on junit at compile time.
** Example 47.4. Dependency registration **
build.gradle
dependencies {
compile group: 'commons-collections', name: 'commons-collections', version: '3.2.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
See Chapter 8 “Basics of Dependency Management” for more information.
Java plugins add some properties to your project. These properties are usually set to default values. If the default value of the property does not match, you can easily change the value. Let's look at an example. Here is the Java project version number and Specifies the Java version that describes the source. It also adds some attributes to the JAR manifest.
** Example 47.5. MANIFEST.MF customization **
build.gradle
sourceCompatibility = 1.7
version = '1.0'
jar {
manifest {
attributes 'Implementation-Title': 'Gradle Quickstart',
'Implementation-Version': version
}
}
You can list the properties of your project by running gradle properties. This will display the properties and defaults added by the Java plugin.
The tasks that the Java plugin adds are exactly the same as those declared in the build file, This is a normal task. This means that you can customize these tasks using the mechanism shown in the previous chapter. For example, setting task properties, adding behavior, You can change task dependencies or replace tasks altogether. In the sample, to add system properties when running the test Configure a test task of type Test.
** Example 47.6. Test system property registration **
build.gradle
test {
systemProperties 'property': 'value'
}
Normally you need to publish the JAR file somewhere. To do this, you need to tell Gradle where to publish the JAR file. Gradle publishes artifacts such as JAR files to the repository. The sample exposes it to a local directory. You can also publish to a remote location or multiple locations.
** Example 47.7. Publishing the JAR file **
build.gradle
uploadArchives {
repositories {
flatDir {
dirs 'repos'
}
}
}
To publish the JAR file, run gradle uploadArchives.
To create an Eclipse-specific descriptor file like .project You need to add another plugin to your build file.
** Example 47.8. Eclipse Plugin **
build.gradle
apply plugin: 'eclipse'
Run the gradle eclipse command to generate the Eclipse project file. For more information on eclipse tasks, see Chapter 67, "Eclipse Plugins" (https://docs.gradle.org/4.4.1/userguide/eclipse_plugin.html).
Here is an example of a complete sample build file.
** Example 47.9. Java Example-Complete build file **
build.gradle
apply plugin: 'java'
apply plugin: 'eclipse'
sourceCompatibility = 1.7
version = '1.0'
jar {
manifest {
attributes 'Implementation-Title': 'Gradle Quickstart',
'Implementation-Version': version
}
}
repositories {
mavenCentral()
}
dependencies {
compile group: 'commons-collections', name: 'commons-collections', version: '3.2.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
test {
systemProperties 'property': 'value'
}
uploadArchives {
repositories {
flatDir {
dirs 'repos'
}
}
}
Next, let's take a look at a typical multi-project build. Illustrate the structure of the project.
** Example 47.10. Multi-project build-hierarchical layout **
Build configuration
multiproject/
api/
services/webservice/
shared/
services/shared/
Note: This sample code is from Gradle's'-all' distribution It is described in samples / java / multiproject.
There are four projects here. The api project generates a JAR file and Provides a Java client for XML Web services to the client. A webservice project is a web application that returns XML. The shared project contains the code used by both the api and the webservice. The services / shared project has code that depends on the shared project.
To define a multi-project build, you need to create a configuration file. The configuration file is in the root directory of the source tree Specifies the projects to include in the build. The configuration file must always be named settings.gradle. This example uses a simple hierarchical layout. The corresponding configuration file is illustrated below.
** Example 47.11. Multi-project build-settings.gradle file **
settings.gradle
include "shared", "api", "services:webservice", "services:shared"
For more information on configuration files, see Chapter 26, "Multi-project builds" (https://docs.gradle.org/4.4.1/userguide/multi_project_builds.html).
For most multi-project builds There are some settings that are common to all projects. The sample uses a technique called configuration injection. Define this common setting in the root project. The root project is like a container, The subproject method iterates over the elements of this container (instance project) and Injects the specified settings. In this way, all archives and some Easily define manifest content for common dependencies.
** Example 47.12. Multi-project build-common settings **
build.gradle
subprojects {
apply plugin: 'java'
apply plugin: 'eclipse-wtp'
repositories {
mavenCentral()
}
dependencies {
testCompile 'junit:junit:4.12'
}
version = '1.0'
jar {
manifest.attributes provider: 'gradle'
}
}
In this sample, the Java plug-in is applied to each subproject. This is because the tasks and configuration properties we saw in the previous section It means that it can be used in each subproject. Therefore, by running gradle build from the root project directory You can compile, test, and generate JARs for all your projects. Also, these plugins are not at the root level It only applies to the subproject section, so The root build does not try to find the Java source file in the root project, Search only within subprojects.
You can add dependencies between projects in the same build. For example, using a project JAR file You can compile another project. The api build file adds a dependency to the shared project. Because of this dependency, Gradle always starts before building the API project. Build the shared project.
** Example 47.13. Multi-project build-Dependencies between projects **
api/build.gradle
dependencies {
compile project(':shared')
}
For information on how to disable this feature See Section 26.7.1, “Disable Dependent Project Builds” (https://docs.gradle.org/4.4.1/userguide/multi_project_builds.html#disable_dependency_projects).
Add the artifacts that will be distributed to the client.
** Example 47.14. Multi-project build-Distribution file **
api/build.gradle
task dist(type: Zip) {
dependsOn spiJar
from 'src/dist'
into('libs') {
from spiJar.archivePath
from configurations.runtime
}
}
artifacts {
archives dist
}
This chapter requires you to build a Java-based project We've seen how to perform some of the tasks. This chapter is not exhaustive. There are many other things you can do with Gradle's Java projects. You can learn more about Java Plugins in Chapter 48, "Java Plugins" (https://docs.gradle.org/4.4.1/userguide/java_plugin.html). Also, a sample Java project from the Gradle distribution Located in the samples / java directory. Otherwise, go to Chapter 8, "Basics of Dependency Management" (https://docs.gradle.org/4.4.1/userguide/artifact_dependencies_tutorial.html).
Recommended Posts