Introduction and Getting Started with Gradle

 

Why choose Gradle

In the past, Ant and Maven once dominated JAVA project management. Ant used XML to automate the construction process across platforms. Later, Maven, the darling of the era, standardized project management to a certain extent and basically became the standard for Java construction. As the project became larger and more complex, Maven also began to lack flexibility, and a Gradle based on the Groovy language was born, and it is likely to become a new generation of software construction hegemon (at least in the JAVA field).

How to understand the Gradle product? The blogger’s personal opinion is: ANT+Maven+DSL == Gradle.

Advantages of Gradle

• Can handle larger and more complex construction projects than Maven
• More native support for multiple languages ​​and multiple platforms
• The construction process is more efficient and supports the latest hardware and operating systems
• Major development plans are transparent
• The community is active and growing rapidly, and more and more international companies adopt it, such as Linkin
• The Groovy language used can complete complex construction tasks and also supports Kotlin language
• DSL is more concise than XML, and Groovy itself can also be used as a glue language for Java

installation

The installation of Gradle is very simple. First install OpenJDK, then install Gradle. Download the ZIP package for Windows version, unzip it to the local directory, set the GRADLE_HOME environment variable, add GRADLE_HOME/bin to the path environment variable, the installation is complete, Linux can refer to The official documents have similar concepts. Users can use the gradle -v command to verify the installation. These initial steps are no different from Maven.

Getting started with Gradle

The design of Gradle runs through two basic concepts: project and task.

Project usually refers to a project, which provides an execution context for tasks. All Plugins either add properties for configuration to the project or add different tasks to the project.

Task refers to the task in the completion process, a logically independent execution process, such as: compiling Java source code, copying files, packaging Jar files, executing a system command, reading and setting Project's Property to complete specific operations... etc. Wait.

A Build action can have 1 to n projects, and each project has 1 to n tasks.

To carry out a simple example, first create an empty directory at will, example D:\temp\tutorial, and then add a blank file build.gradle in it, enter the following code:

task taskA {
    doLast {
        println 'Hello world!'
    }
}

A task is defined in the file: taskA, with the content "println'Hello world!'". The doLast instruction is wrapped so that the block is executed at the end when the task is executed. Perform it:

gradle -q taskA

"Hello world!" is output, where -q means quiet mode, and only the necessary information during the build process is output.

There can be a dependency relationship between tasks. Use the dependsOn keyword to see an example:

task taskB(dependsOn: 'taskA')  {
    println 'taskB'
}
	
task taskA {
    doLast {
        println 'Hello world!'
    }
}

Perform the same:

gradle -q taskA

Display the result, execute taskB first and then execute taskA:

taskB
Hello world!

Use the defaultTasks command to set the task to be executed when no task is specified, add:

defaultTasks 'taskA', 'taskB'

Execute`:

gradle -q

Although we also have taskB by default here, the smart Gradle knows that taskB depends on taskA, so taskB is only executed once by taskA. Here we must understand its execution order and logic. If defaultTasks uses repeated tasks, it will also be ignored:

taskB
Hello world!

Gradle dependency library management

Gradle and Maven are almost the same in dependency library management, and the core concepts are the same, but Gradle syntax is more streamlined, and there are more flexible custom configurations.

Maven

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>5.2.13.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
    </dependency>
</dependencies>

Gradle

dependencies {
    compile('org.springframework:spring-core:5.2.13.RELEASE')
    testCompile('junit:junit:4.12')
}

It can be noted that Gradle is indeed more suitable for human reading and management.

Comparison of the two:

• Gradle, like Maven, supports transitivity in dependency configuration, and unlike Maven, it also supports exclusion of transitivity and closing transitivity.
• The dependency scope of Gradle is basically the same as that of Maven, but it is defined by configuration and supported and enhanced by plug-ins. So in addition to the basic scope of compilation and execution time, Gradle can also customize many configurations, which can be more flexible to achieve more Complex construction requirements.

The warehouse configuration related to the dependency library is very flexible and supports a variety of repositories. Examples:

repositories {
    mavenCentral()          
}
repositories {
    jcenter()              
}
repositories {
    maven {
        url "http://repo.mycompany.com/maven2"    
    }
}
repositories {                        
    flatDir {
        dirs 'lib'
    }
}
repositories {                            
    ivy {
        url "http://repo.mycompany.com/repo"
    }
}

These warehouses and protocols are all built-in support for Gradle, which is very convenient, especially the perfect cooperation with maven. The existing resources are used up and used up. If they are not enough, Gradle also has a self-expanding mechanism, which is simply not more powerful.

Gradle build

Similar to Maven, Gradle is also packaged and generated with a thing called artifact. Thanks to the aforementioned characteristics of Gradle itself, artifacts can be implemented more flexibly in Gradle. E.g:

// provide archives
apply plugin: 'java'

// jar artifact
task myJar(type: Jar)
artifacts {
    archives myJar
}

// file artifact
def someFile = file('build/file.txt')
artifacts {
    archives someFile
}

In this way, several definitions for generating artifacts are simply defined. According to different scenario requirements, text files, jar packages or zips are generated, and they can also be uploaded to the server.

It can also support custom tasks to complete the artifact, please refer to more advanced teaching.

Gradle plugin

We have already had the concept before, but there is still an important link missing in the actual application of the project: plug-ins. Gradle now supports many plug-ins, which brings great convenience to developers. Here is the introduction of the most commonly used Java plug-ins.

To use the Java plug-in, just add this sentence in build.gradle:

apply plugin: 'java'

Java project layout Gradle, like Maven, adopts a "convention over configuration" method for layout. The layout method is the same as that of Maven, and Gradle can also support advanced custom layouts. These directories are generally called source sets.

The Java plug-in also defines a bunch of tasks that we can use directly, such as: clean, test, build, etc. Gradle's Java plug-in makes the life cycle more complicated, but therefore more flexible.

Concluding remarks

Gradle has developed into a very powerful software construction ecology. It is recommended to learn this tool through learning by doing, and you can gradually realize that this investment is worthwhile.