Brief Introduction to Gradle

Introduction

The topic of this review will be the Gradle automatic build system. In English, build systems are called Build Tools . Why is this even needed? Manual assembly of projects in Java is a rather time-consuming process. You need to correctly specify the libraries and frameworks that the project needs, on which the project depends. Here you can read an excellent article on Habré: " Working with Java on the command line". Sooner or later you will start creating some scripts to automate this process. Now imagine that all developers around the world do this and everyone rewrites what someone has already written for their project. And then the systems project builds that automate this process.In addition, on the one hand, they allow you to build your project the way you want it, on the other hand, provide you with more or less standardized tools.An alternative to Gradle is the Maven automatic build system.These two build systems on the one hand different, but on the other hand, they have a number of similarities. There is a material on this topic on the Gradle website: " Migrating from Maven to Gradle". As stated in this guide, Gradle and Maven have a different perspective on how to build a project. Gradle is based on a graph of tasks (task), which can depend on each other. Tasks do some work. Maven uses a model of certain phases, to which certain "goals" (goals) are attached. In these goals, some work is done. However, with such different approaches, both build systems follow the same convention and dependency management is similar. To start using Gradle, you need it download.In google or in yandex, enter "Gradle Build Tool" and in the first results we see the official site: https://gradle.org On the Gradle main page there is a link with the text "Docs", which leads to the Gradle documentation. First we need to install (Install) Gradle, so we are interested in the " Installing Gradle " documentation section. There are many installation methods, including the "old fashioned" method, ie. manually (" Installing manually "). Download according to the instructions a file of type " binary-only ", which will have a name like gradle-5.1.1-bin.zip. Next, unpack the archive and set the PATH environment variable according to the instructions. Most importantly, after executing the instructions, the command gradle -vshows the version of the installed Gradle. There may be a problem with the fact that when determining the location, the system will not find Gradle where you want. Therefore, on Windows you can execute (on * nix there are analogues): for %i in (gradle.bat) do @echo. %~$PATH:i Now, perhaps, we can start dating.

Gradle project initialization

I would like to note right away that Gradle is about performing tasks called tasks (I will call them tasks). Tasks are provided by various plugins . I advise you to read more about plugins in the official documentation: " Using Gradle Plugins ". There is a set of "Core Plugins" that are always there when Gradle is installed. There are different categories of these plugins, but we are interested in the " Utility " category. This set has a " Build Init Plugin " plugin that provides tasks for initialization (Initialization) Gradle project. We are interested in creating a project type: " java-application ". Let's execute Gradle task: gradle init --type java-application We will answer some questions along the way, for example, that we want to use the Groovy DSL (the standard task description language for Gradle) and the JUnit testing framework (we will talk about this in another review). After creation, we will get the following set of files: Firstly, after initialization, we get a special wrapper preconfigured for our version of Gradle - this is such a special script. I advise you to read more about it in the official documentation - " The Gradle Wrapper ". Second, we see Gradle Build Script - build.gradle file. This is the main file, which describes which libraries and frameworks our project uses, which plugins need to be connected to the project, and describes various tasks. I advise you to read more about this file in the official documentation: " Build Script Basics ".

Plugins and Tasks

If we look at the contents of the Build Script now, we will see the plugins section:

plugins {
    id 'java'
    id 'application'
}

These are the same plugins that we talked about earlier. And if there are plug-ins, then there are tasks that are now available to us. We can run the gradle tasks command and see what we can do with the project now: For example, by executing gradle runwe will run the main class of our java application: As we can see, the bottom is written in the same way. 2 actionable tasks: 1 executed, 1 up-to-date What does this mean? This means that 2 tasks were completed in total: it is up-to-date, that is, the state is up-to-date and nothing has been done. We can execute the so-called "Dry Run": gradle run -m Let's execute this command, we will see what tasks will be executed in order to execute the run task: As we can see, a total of 4 tasks were completed: before run was executed, it executed the task classes according to the dependency. Tus classes itself has 2 dependencies and therefore it also performed compileJava and processResources. When we perform a task, we can complete it by viewing a certain level of logs (the level of logging determines how important messages we want to see). For example, we can execute gradle run -i. This will show us, among other things, informational messages of the form:

Task :classes UP-TO-DATE
Skipping task ':classes' as it has no actions.

For more information about logging in Gradle, I advise you to refer to the official documentation: " Gradle Logging ". As we can see, the classes task was skipped because it is UP-TO-DATE , that is, the state is up-to-date, nothing needs to be done, so there were no actions. This is because by default Gradle has " Up-to-date checks " or the so-called incremental build. You can read more about this mechanism in the Gradle documentation: " Up-to-date checks (AKA Incremental Build) ". But this mechanism can be disabled by running a task with the --rerun-tasks flag. For example, gradle run --rerun-tasks. Then we will see: 2 actionable tasks: 2 executed As you can see, the number of completed tasks takes into account only the first level of the graph, that is, the run task itself and those tasks on which it directly depends, that is, classes. Tasks that classes depend on are not counted here (although they are executed when the classes task is executed). You should also read about tasks:

• " Authoring Tasks ": Describes creating your own tasks.
• " Writing Custom Gradle Tasks ": A step by step guide to creating tasks.
• " Build Script Basics ": Basics about tasks and their usage.

Dependencies

One of the main tasks of any build system is dependency management, that is, which libraries / frameworks our project needs. The build system must ensure that they are available at the right time and build the final artifact of our application in the right way. By default, after gradle init for java-application, we will see the following content in the build script:

dependencies {
    implementation 'com.google.guava:guava:26.0-jre'
    testImplementation 'junit:junit:4.12'
}

It is immediately clear what we are connecting. But without some understanding, it is not clear what implementation and testImplementation are? Here we need to turn again to the Gradle documentation, since Gradle's documentation is well written. It's called " Managing Dependency Configurations ". As stated in the documentation, each dependency is declared with some scope - the area within which this dependency will be available. This scope is designated by some configuration, each of which has a unique name. It's also interesting that a lot of Gradle plugins add predefined configurations. To find out what configurations we have we can run: gradle --console plain dependencies Thus, we will see a list of all available configurations and their dependencies. We can filter this list so that we only see the available configurations: gradle --console plain dependencies | find " - " How do we figure out what to use? There is a little to read here. Because Since we're using the "Java" plugin, we'll start with its documentation and the " Dependency management " section. Here we see that there used to be a configuration (aka scope) called "compile" and meant "dependency needed at compile time". But then it was replaced (in English Superseded) with implementation. You can read more about the replacement in the " API and implementation separation" section.". It turns out that this dependency will be on the "compile classpath". But sometimes we want our dependency to be included in the final artifact. Why? For example, we will have an executable jar that should contain everything we need in itself. What then do we Firstly, there is no such support "out of the box" (that is, by default, without any additional actions). This is explained by the fact that everyone wants to build the archive in their own way, and Gradle tries to be minimalistic. We also cannot use jar archives on the classpath (without any additional code manipulations), as it doesn't work like that (See " Oracle: Adding Classes to the JAR File's Classpath " for more details.) Therefore, the most beautiful way is the following code in the build script:

jar {
    manifest {
        attributes 'Main-Class': 'jrgradle.App'
    }
    from configurations.compileClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}

In the jar task settings we specify what will be added to the jar file's manifest (see " Oracle: Setting an Application's Entry Point "). And then we say that all the dependencies that were needed for compilation, we will include them in the jar. An alternative would be to use the Gradle Shadow Plugin . It may seem complicated, but other plugins can make life easier. For example, when creating a web application (as opposed to a regular running java application), we will use a special plugin - " Gradle War Plugin", which has a different behavior and our life will be easier there (all the necessary dependencies will be added to a separate special directory by the plugin itself. Such work is regulated by how web applications should be arranged. But that's a completely different story).

Results

Gradle is an excellent choice as project build systems. This is confirmed by the fact that developers of such well-known projects as Spring and Hibernate use it. Above were considered only the most basic things. Behind them is a million features and opportunities that developers have. Gradle also supports the creation of multi-project projects, which is not covered in this review, but Gradle itself has an excellent tutorial: " Creating Multi-project Builds". I hope this review also showed that Gradle's documentation is written in 5+ and you can easily find what you need if you know where to look approximately. And this will come when you understand the basics. In addition, Gradle has awesome tutorials. Finish I would like a small list of what else you can see on Gradle:

• Gradle Training (Often free).
• Gradle for Android and Java
• Building Java Web Applications
• Evgeny Borisov — Power of Gradle (2013)

#Viacheslav