Did you know that there is a Java build system that does not use angle brackets? More and more projects are using Gradle as an integrated part of their development process. In short, Gradle provides a Groovy DSL for declarative builds based on build conventions. This blog post aims to give you a kickstart if you want to start exploring Gradle yourself by introducing some core concepts and commands.
Installation
If you have not used Gradle before, you must install it first (unless someone has already migrated your project to Gradle, but we get to that later). Windows and Linux users can download the latest binaries from Gradle’s download page and unpack the zip. Make sure that you add the GRADLE_HOME/bin folder to your PATH environment variable.
For Mac users, you can use Homebrew to install the latest package:
% brew -v Homebrew 2.7.2 Homebrew/homebrew-core (git revision 3c379; last commit 2021-01-11) Homebrew/homebrew-cask (git revision 40d45; last commit 2021-01-11) P.S Tested with Homebrew 2.7.2 and macOS Big Sur 11.1. /usr/local/Cellar/ Directory listing for the /usr/local/Cellar/. 🍻🐧 Core formulae for the Homebrew package manager on Linux - Homebrew/linuxbrew-core.
Verify that the installation works by calling Gradle from your command line:
If everything is ok, you will see information about the Gradle version, your JVM, OS and so on. Please consult the installation guide if you have any problem.
Creating a Project
As of Gradle 1.6 that was released the other day, Gradle provides some support for starting a project from scratch. When executed, the incubating build setup plugin generates some tasks that will generate the basic Gradle files:
Converting a Maven Project
The setup build plugin can also be used to convert a Maven project to a Gradle project. Let’s try it out by first using a Maven archetype to generate a simple Maven project:
Press enter to accept the suggested archetype, i.e. the maven-archetype-quickstart, and then press enter once more to accept the latest version. I use com.jayway.gradle.example as ‘groupId’, and getting-started as ‘artifactId’. Just keep pressing enter to acknowledge the rest of the suggested default values. Maven generates a simple project with a single class, an accompanying test class and a Maven pom.xml build script. Step into the directory and make sure that it works by executing Maven’s test command:
Now, by invoking the setupBuild command the basic content from Maven’s pom.xml file is extracted and converted into Gradle’s corresponding build.gradle file:
So far so good, now let’s proceed with some actual Gradle work.
Homebrew Gradle Update
Gradle Tasks
Each Gradle project is associated with a set of tasks. Plugin such as the Gradle Java plugin provide their own tasks, and developers can create their own tasks. Consequently, different projects have different tasks. To see what tasks are available for a particular project, the gradle tasks command is executed:
The available Gradle tasks are listed together with a brief description, e.g.
- build – Assembles and tests this project.
- clean – Deletes the build directory.
- help – Displays a help message
- tasks – Displays the tasks runnable from root project ‘getting-started’ (some of the displayed tasks may belong to subprojects).
- test – Runs the unit tests.
- install – Installs the ‘archives’ artifacts into the local Maven repository.
To execute a task, one simply calls Gradle and the name of the task:
As a result, Gradle compiles the source file, compiles the test file and executes the test as one would expect. That is actually several different tasks being executed. Underlying tasks will be executed automatically if required.
Gradle Files
When the gradle setupBuild command was executed, a set of files was generated. The build.gradle is the most important of them:
- The first two lines declare the inclusion of two plugins, namely the previously mentioned Java plugin and the Maven plugin.
- The group and version id was imported from the Maven’s pom.xml together with a generated description.
- Next, you may wonder why Gradle has specified such old versions of the Java source and Java target files? Looking at the origin
pom.xmlfile does not give any clues, because they were not specified there. The answer resides in Maven’s effective pom (mvn help:effective-pom) and the implicit usage of the maven-compiler-plugin which uses the 1.5 version by default. Depending on your project deployment environment, upgrading to a more recent version is strongly encouraged. - The repositories and dependencies have also been included from the Maven script.
Another file that was generated was the settings.gradle file, which is used particularly for multi-project builds.
Lastly, the files gradlew, gradlew.bat, gradle/wrapper/gradle-wrapper.jar and the gradle/wrapper/gradle-wrapper.properties have all been added by the Gradle Wrapper. The first two files are command line scripts (for *unix and Windows environment respectively) that are used for executing the jar file with the specified properties, which in turn downloads and installs Gradle automatically. In other words, by adding these files to the version control system, it is possible for new team members and continuous integration system to use Gradle without installing Gradle on beforehand. As a bonus, it provides a way for the team to make sure that everyone is using exactly the same version of Gradle for the project they are developing.
Homebrew Gradle Versions
Gradle Plugins
The purpose of the Gradle Plugins is to enrich projects by adding tasks, dependencies, properties and default values.
The Java plugin was briefly mentioned earlier. One of its features is that it adds the same folder structure convention as Maven (src/main/java as root for the production code src/test/java as root for the test code). The external dependency management system is another important feature provided by the Java plugin.
The Maven plugin was also added to the project when it was created. It allows Gradle to interact with Maven based environment, such as installing the binary file to your local Maven repository, uploading it to a remote repository, etc.
Several other plugins are bundled with the Gradle distribution. For example, there is a Jetty plugin, support for development tools such as Eclipse and FindBugs and support for other programming languages such as Scala and Groovy. Additionally, there are a number of external plugins, including the Android Gradle Plugin which one of my colleagues blogged about some time ago.
Resources
Use this page to configure settings for Gradle projects that were created, opened, or linked.
To configure the offline mode, refer to the Gradle tool window. If you need to add VM options, refer to the Gradle VM options.
| Item | Description |
|---|---|
| Gradle user home | Use this field to specify the location of stored Gradle caches, downloaded files, and so on. If Gradle location has been defined by the environment variables If the Gradle location has not been deduced from the environment variables, specify it manually, or click , and select the desired directory. Note that the value entered in this field takes preference over the environment variables. IntelliJ IDEA also supports the custom Gradle location installed from the homebrew package manager. |
| Generate *.iml files for modules imported from Gradle | Select this option to store the generated .iml and library files in the .idea directory instead of idea.system.path. It might be helpful in the following cases:
When you make changes in your Gradle project, the .iml files get changed as well so don't forget to push them along with the other project's changes under VCS. |
| Gradle projects | You can have several linked Gradle projects when you work in IntelliJ IDEA. You can configure settings for each selected project. |
| Download external annotations for dependencies | When this checkbox is selected, IntelliJ IDEA downloads a file with a set of external annotations from the JetBrains public repository. |
| Build and run | Use this section to specify what IntelliJ IDEA should use when you run tests, build, or run tasks in the selected linked project. |
| Build and run using | Use this list to select how you want to build and run your project. Use Gradle as a default option or select IntelliJ IDEA. In this case when you select Build | Build Project from the main menu, IntelliJ IDEA goes through source sets in all modules executing the Gradle task If you have a pure Java or a Kotlin project, it is sometimes better to select IntelliJ IDEA for building a project. IntelliJ IDEA supports the incremental build which significantly speeds up the building process. Yet, keep in mind that the IntelliJ IDEA compiler does not support some parts of the Gradle project build processing and might cause problems in building your project correctly. |
| Run tests using | Use this list to select how you want to run tests in your project. Use Gradle as a default option or select IntelliJ IDEA. |
| Gradle | |
| Use Gradle from | Use this list to configure a Gradle version for your project. You can select one of the following options:
|
| Gradle JVM | Use this field to specify the JVM under which IntelliJ IDEA will run Gradle when you import the specified Gradle project and when you execute its tasks. The default is set to your project JDK. This field overrides any other Gradle JVM selection. You can check a process of how IntelliJ IDEA selects the Gradle JVM version in the Gradle JVM selection section. |