The Definitive Gradle Guide for NetBeans IDE
Gradle is a build tool like Ant and Maven (only it is better :)). If you don't already know Gradle, you should visit http://www.gradle.org as they have a vast amount of (good) documentation. For the rest of this documentation (the original is found here), I will assume that you are somewhat familiar with Gradle. The plugin discussed in this guide is found here:
Related articles: "Why I like using Gradle in NetBeans IDE" by Martin Steffen and "Why I like using Gradle in NetBeans IDE" by Douglas Maxwell.
The plugin heavily relies on the Tooling API of Gradle. This Tooling API is used for discovering the structure of your project and is also used to execute tasks. In both cases, the Tooling API relies on the services of the so called Gradle daemon. The Gradle daemon is a background Java process which is automatically started by the Tooling API if not running.
Once started, a Gradle daemon will live for 3 hours by default (and you cannot adjust the default in the Tooling API). What is relevant to you is that this daemon is not really a lightweight process (by default it uses -Xmx1024m). However it is possible to spawn more daemons inadvertently: If the daemon is currently busy (executing one of your task or loading a model for the plugin) and you attempt to execute a task, a new daemon will spawn and will remain with you for 3 hours (unless you forcibly kill the daemon process which is a java process).
Also, if you adjust the JVM arguments, Gradle might spawn a new daemon simply because the one running has been started with different arguments (it will not do so if feels that your arguments are ok with the currently running daemon). The plugin will do its best not to execute tasks concurrently if not necessary but regardless you should be aware of the Gradle daemon running in the background even after you close NetBeans.
Global SettingsAfter you have installed the Gradle plugin for NetBeans, you might first want to check the global settings in NetBeans. These settings allow you to set global defaults for loading and understanding your Gradle projects. Although the plugin will likely work without touching these settings, it is in your best interest to set them properly. You may find these settings in "Tools/Options/Miscellaneous/Gradle".
Once you have adjusted the global properties to your liking, you might proceed to open an existing Gradle project (or you might create a new one with the wizard which will also open the created project). Opening the project works the same way as with any other NetBeans project: Select the directory of the project and choose open project. There are three kinds of directory which this plugin recognizes as Gradle projects:
- The directory contains a settings.gradle file.
- The directory contains a build.gradle file.
- The directory contains a .gradle file with the same name as its containing directory.
Project StructureThe project structure of the opened project (in the "Projects" window) should look similar to usual Java projects (note that this plugin only supports Java based projects). Something what you might see is that if the project you opened contains subprojects (e.g., you have opened the root project), you will have a "Subprojects".
The "Subprojects" node can be unfolded to browse all the subprojects and open them from here if you want. Personally, I usually open the root project and use it to open whatever subprojects I currently need. The "Build Scripts" node is somewhat special to this plugin as well: It contains the .gradle files found in the directory of the project (does not search recursively, if you need other files, you should use the "Files" tab). Other nodes are what their name suggest.
Project PropertiesOnce you had enough of the "Projects" tab or see files with errors even though they should compile, head to project properties. The project properties can be opened from the context menu of the project node: Here choose "Properties". There is a lot you can set here but first and foremost, you should know how these properties are stored: All the subprojects in a Gradle project share the same properties. This was a design decision to avoid too many (most likely unnecessary) configurations.
The default profile is stored next to the "settings.gradle" file of the project (if there is none, then in the directory of the project) and is named ".nb-gradle-properties". This file was designed so, that usually you can safely commit it to your VCS (other IDEs will simply ignore it). There is another directory located next to ".nb-gradle-properties" called ".nb-gradle". This might store files you might not want to commit to your VCS. Though currently, only the additional profiles you create will be stored here. So understanding this you should adjust the properties of the project. This includes properties which this plugin might not be able to deduce from the build script and many others. For detailed information about the properties, read the more detailed guide.
Context menu of the ProjectYou can find the usual build commands here (e.g.: build, test). What is important to know is that each build command is mapped to a specific gradle command and each of them is completely customizable. You should read the build command guide. What is really important to know here is that the plugin will not recognize changes to the build script automatically.
If you have changed the build script of the project, you should click "Reload Project" in the context menu. Note that it is not necessary to reload a project after every change to the build script.
Usually, you only need to reload if you have adjusted the dependencies of the project (reloading the project has no effect on executing tasks). The plugin will also do its best to reload projects depending on this project (and are in the same multi-project build) and the dependencies. Actually, as currently implemented the plugin reloads every project in the same multi-project build.
You are able to execute and save tasks you intend to use often. These tasks can be added to the "Custom Tasks" item of the context menu of the project. Custom tasks are stored with the project properties (in the same file), so as with other properties they are shared across the projects of a multi-project build. Please read the more detailed guide of custom tasks.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)