Gradle User Guide (chapter 7:java plugin)

2. Java Plugin

   As we can see, gradle is a generic build tool. It can build a build script that you care about and implement. It's out of the box, however, it won't build anything unless you add code to your build script.

   Most Java projects have very similar underlying operations: compiling Java source files, running unit tests, and creating jar packages that contain class files. If you don't want to add these operational codes for each project, that's great. Gradle Use plug-ins to solve this problem. This plugin usually expands it by configuring your project in some way, adding a series of preconfigured tasks to do something useful. Gradle comes with a lot of attachments, and of course, you can also write your own attachments and share them with others. One of them is the Java plugin. This plugin adds some tasks to your project: compiling, testing your Java source files and generating jar packages.

   The Java plug-in is contract-based. This means that the plug-in defines default values in many aspects of the project, such as where the Java source files are located. If you follow this convention in your project, you generally do not need to modify your build script extensively to have an available build. Gradle allows custom plugins if you don't want to or can't follow the conventions. In fact, because support for Java projects is implemented through plugins, if you don't want to, you can build a project without using plugins.

   We'll dive into more examples of Java plugins in a later section, relying on management, multi-project content. In this chapter, we just want to give you a preliminary idea of how to build a Java project using a Java plugin.

3. A basic Java project

   Let's look at a simple example. Using the Java plugin, add the following to your build file:

   This is all you need to define a Java project. This adds the Java plug-in to your project and it adds the task to your project.

   Gradle will find the source code in your production environment ? Src/main/java ? And your test source code Src/test/java. In addition, The files under src/main/resources will be included in the CLASSPATH for running tests. All output folders are created under the build directory, and the jar is included in the Build/libs directory.

   The Java plugin adds many tasks to your project. However, you only need a few tasks to build your project. Our most common task is to build task build tasks, which make a complete build of your project. When you execute Gradle build, Gradle will compile and test your code, creating a jar package containing your main classes and resources.

   Some other useful tasks:

   Clean

   Delete the build directory and delete all the build files.

   Assemble

   The code compiles and packages and does not run unit tests. Other plugins can also add more actions to this task. For example, if you use the war plug-in, this task can also build a war package in your project.

   Check

   Compile and test the code. Other plugins can add more checks to this task. If you use the Checkstyle plugin, this task will run a checkstyle check on your code.

   Typically, a Java project will have some externally dependent jar packages. If you use these jar packages in your project, you need to tell gradle how to find them. Gradle artifacts, such as jars, are placed in a warehouse. This project can be used to crawl project dependencies or publish project artifacts, or both. In this example, we will use the public Maven library.

   Let's add some dependencies. Here we declare that our production has a compile-time class that relies on the Commons collections, and the test class relies on the JUnit

   You can find more in the eighth chapter: dependency Management.

   Custom Projects

   The Java plugin adds a series of properties to your project. These properties typically give default values at the beginning of the project. If they don't fit, we can change these values very conveniently. Let's take a look at these examples. Here we will specify the version number for the project, along with the version number we wrote in the source file. We will also add some attributes to mainfest.

   The Java plugin can add recurring tasks, as declared in the build file. This means that you can use any of the mechanisms shown in the previous chapters to customize these tasks. For example, you can define the nature of these tasks, add behaviors to tasks, change task dependencies, or completely replace a task. In the example, we will configure the test task, which type ? test, add a system property when performing the tests:

   Publish the Jar file

   Usually we need to publish the jar package. To do this, you need to tell Gradle where to publish these jar files. In Gradle, the components are published to the warehouse. example, we publish to the local repository. You can also publish to a remote location or to multiple locations.

   Publish the jar package, run Gradle uploadarchives

   Create Eclipse Project

   To create a eclipse-specific attribute descriptor file, such as. Project, you need to add another plugin to your build file.

   Now execute the gradle Eclipse command to generate the Eclipse project file. Can you find out more about Eclipse in the chapter ? Eclipse plugin

   Summarize

   Here is an example of the complete build file:

5. multi-project build

   Now let's look at a typical multi-project build. The following is the layout of the project:

   Here we have 4 items. The project API generates a jar file to send to the client that provides the XML Network service to the Java client. Project WebService is a webapp that returns XML. Project shared includes APIs and webservice. The project services/shared relies on shared.

   Define a multi-project build

   To define a multi-project build, you need to create a setup file settings. This setting file is in the root directory of the source tree and specifies which project builds are included. It must be named Settings.gradle. For this example, we use a simple hierarchical layout. The following is the corresponding settings file:

   Common configuration

   There are some common configuration items for most multi-project builds. In the example, we use a common configuration in the root project, using technical configuration injection to configure injection. Here, the root project is like a container, and the subproject method traverses the container-the project in this instance-and then injects the configuration. This makes it easy to define the list for all the file contents and some common dependencies.

   Notice that the Java plug-in in our example works for each subproject. This means that the tasks and configuration properties we see in the previous section are available. So, you can use Gradle build in the root directory to compile, test package source files.

   Also note that these plug-ins are only used in sub-projects, so you cannot find the source files you expect in the root project and are only found in the subproject.

   Dependencies between projects

   You can add dependencies between projects in the same project. For example, a jar package is used to compile another project. In the API build, we define that it relies on shared. Due to this dependency, Gradle will ensure that the project Shraed always precedes the project API.

   Create a distribution?

   We create a distribution that is shared to the client:

7. What is the next chapter?

   In this chapter you have seen the tasks you typically need to build a Java project. This chapter is not exhaustive and you can do more with the Java project. Can you find more Java plugins ? Chapter VII ,? Java plugin ?, You can also find more examples of Java projects in the Gradle distribution Samples/java directory

Gradle User Guide (chapter 7:java plugin)