Gradle notes--java Build Getting Started

Gradle is a generic build tool that allows you to build anything you want to accomplish with its build script, but only if you need to write the code for the build script first. And most of the projects, their build process is basically the same, we do not have to write the construction code for each project, because Gradle has provided us with the appropriate plug-ins. Gradle itself with a lot of plug-ins, and for Gradle no plug-ins, you can go to GitHub to see if other people realize, or their own implementation. For Java projects, Gradle has a Java plugin that provides functionality like compiling, testing, packaging, and so on.

Here is a brief introduction to the Java plugin.

The Java plugin defines a number of default settings for a build project, such as the source file directory, the compiled file location, and so on. If you follow the default rules, then the build script will be simple. Of course, if the project structure is different, you can also specify these rules yourself. It is not introduced here, just a basic usage.

1. Using the Java plugin

Just add the following code to the build script:

[Plain]View Plaincopy

1. Apply plugin: ' java '

Defining a Java project requires just the addition of a code that adds a Java plug-in and some built-in tasks for you.

By default, Gradle will find your source code in Src/main/java, find your test codes in Src/test/java, and the files under Src/main/resources will be packaged, src/test/ The files under resources will be included in the classpath for testing. All output files are stored in the build directory, and the generated jar is inside the build/libs.

2. Build the Project

The Java plugin defines a number of tasks for you, which can be seen by the Gradle Tasks command mentioned earlier. When the Gradle build is executed, Gradle compiles, tests, and hits the source and resource files into a jar package.

In addition to build, there are several common tasks, as follows:

Clean: Deletes the build directory and other build-time files.

Assemble: Compiles and packages, but does not perform unit tests. However, some other plugins may enhance this task, such as the war plugin will then play the war package.

Check: Compile and test the code. Other plugins may enhance this task. For example, the Code-quality plugin will allow this task to execute checkstyle.

3. External dependencies usually a project will have many external dependencies, and we need to tell Gradle where to find these dependencies in the build script. For example, if you use the MAVEN central repository, we can add the repository with the following code: [Plain]View Plaincopy

1. repositories {
2. Mavencentral ()
3. }

Then add dependencies through the following code: [Plain]View Plaincopy

1. dependencies {
2. Compile group: ' Commons-collections ', Name: ' Commons-collections ', Version: ' 3.2 '
3. Testcompile group: ' JUnit ', Name: ' JUnit ', version: ' 4.+ '
4. }

The above code declares that at compile time, dependency commons-collections is required, and junit is required during the test period. The next article will have more detailed notes on what to rely on.
4. As mentioned earlier in the customization project, the Java plug-in defines a number of default configurations for the project, which can be defined by ourselves if we need to. Specify the project version number and the JDK version number, as in the following example, and add some attributes to the jar package's manifest file: [Plain]View Plaincopy

1. Sourcecompatibility = 1.5
2. Version = ' 1.0 '
3. Jar {
4. Manifest {
5. Attributes ' Implementation-title ': ' Gradle Quickstart ', ' implementation-version ': Version
6. }
7. }

Java plug-ins add common tasks, so the gradle mechanism described in the previous chapter can also be used here, such as modifying a task's dependencies, adding task behaviors, or even rewriting a task, and so on. The following example modifies the test task to add a system property: [Plain]View Plaincopy

1. Test {
2. Systemproperties ' property ': ' Value '
3. }

5. Release the jar package The following code is to publish the jar package to local. Post to the Maven warehouse or Jcenter warehouse for further discussion. [Plain]View Plaincopy

1. uploadarchives {
2. repositories {
3. Flatdir {
4. Dirs ' Repos '
5. }
6. }
7. }

Execute Gradle uploadarchives to publish the jar package.
6. Create an Eclipse project if you want to import the project into eclipse, you need to use an Eclipse plugin: [Plain]View Plaincopy

1. Apply plugin: ' Eclipse '

Executing gradle eclipse generates the Eclipse project file, which is further detail about this plugin.
7. Summary The following is a complete Java project build script: [Plain]View Plaincopy

2. Apply plugin: ' java '
4. Apply plugin: ' Eclipse '
8. Sourcecompatibility = 1.5
10. Version = ' 1.0 '
12. Jar {
14. Manifest {
16. Attributes ' Implementation-title ': ' Gradle Quickstart ', ' implementation-version ': Version
18. }
20. }
24. repositories {
26. Mavencentral ()
28. }
32. dependencies {
34. Compile group: ' Commons-collections ', Name: ' Commons-collections ', Version: ' 3.2 '
36. Testcompile group: ' JUnit ', Name: ' JUnit ', version: ' 4.+ '
38. }
42. Test {
44. Systemproperties ' property ': ' Value '
46. }
50. uploadarchives {
52. repositories {
54. Flatdir {
56. Dirs ' Repos '
58. }
60. }
62. }

8. Multi-Project construction project structure: [Plain]View Plaincopy

1. multiproject/
2. api/
3. services/webservice/
4. shared/

You first need to create a Settings.gradle configuration file that declares which projects to include in the build. The contents of the file are as follows: [Plain]View Plaincopy

1. Include "Shared", "API", "Services:webservice", "services:shared"

Multi-project construction, will be elaborated later.
9. Public configuration for multi-project construction, there are some configurations that are common. Gradle will define some public configurations on the root project using a method called configuration injection. So in this case, these public configurations can be defined in the configuration file of the root project, and the child project's configuration file will iterate over the configuration and inject it into its own configuration. Here is the sample code: [Plain]View Plaincopy

2. subprojects {
4. Apply plugin: ' java '
6. Apply plugin: ' ECLIPSE-WTP '
10. repositories {
12. Mavencentral ()
14. }
18. dependencies {
20. Testcompile ' junit:junit:4.11 '
22. }
26. Version = ' 1.0 '
30. Jar {
32. Manifest.attributes provider: ' Gradle '
34. }
36. }

The above configuration applies java and ECLIPSE-WTP plug-ins to the CBD project, declares the MAVEN central repository, adds dependent JUnit for the test period, and defines the properties of the project version package and the manifest file in the jar package.
10. Projects rely on projects in the same build to build project dependencies. For example, if the API subproject relies on the jar package generated by the share subproject, the following code can be used in the build script of the API subproject: [Plain]View Plaincopy

1. dependencies {
2. Compile project (': Shared ')
3. }

11. Multi-item packaging and publishing [Plain]View Plaincopy

1. Task Dist (type:zip) {
2. DependsOn Spijar
3. From ' Src/dist '
4. Into (' Libs ') {
5. From Spijar.archivepath
6. From Configurations.runtime
7. }
8. }
10. Artifacts {
11. Archives Dist
12. }

I don't understand this code yet. Remember, first.
The next article will be a note that Gradle relies on management fundamentals.
This series of blogs is a gradle user manual note. This article is the seventh chapter in the Gradle 1.2 Java build Quick Start note, the code in the blog is derived from this document.

This article original, reproduced please indicate the source: http://blog.csdn.net/maosidiaoxian/article/details/40656311

Gradle notes--java Build Getting Started