Chapter 10. IDE support and tooling
This chapter covers
- Using IDE plugins to generate project files
- Managing Gradle projects in popular IDEs
- Embedding Gradle with the tooling API
While Gradle’s target runtime environment is the command line, editing build scripts happens in a text editor. The types of editors that developers use range from simple screen-oriented editors like vi or Emacs, to full-blown integrated development environments (IDEs) like Eclipse and IntelliJ IDEA. IDEs can boost a developer’s productivity tremendously. Functionality like syntax highlighting, navigation through keyboard shortcuts, refactoring, and code completion generation save valuable time during development and make implementing code a more enjoyable experience. Developing Gradle code should be no different.
IDEs describe organizational units with the notation of a project, similarly to a Gradle project. A project defines a type (for example, web versus desktop application), external dependencies (for example, JAR, source, and Javadoc files), plus individual settings. With the help of project files, a project can be opened in an IDE and can allow for sharing configuration data with other developers. Unfortunately, the formats of these project files are not unified across IDE products. Among the most common formats are XML and JSON.
Gradle allows for generating IDE project files with the help of plugins. The standard Gradle distribution provides two out-of-the-box plugins: Eclipse and IDEA. Each plugin understands how to model IDE-specific project files. The plugins also expose a powerful DSL for customizing the generated project settings. To generate project files, you’ll need to apply the IDE plugin to your build script, execute the task provided by the plugin, and import the generated project files into your IDE, as shown in figure 10.1.
A couple of years ago, Gradle was the newcomer among the top dogs Ant and Maven. None of the IDE vendors provided any significant Gradle support. To import a project built by Gradle, you had to generate the project files using the provided Eclipse and IDEA plugins. If you used a different IDE (for example, NetBeans), you had no tooling support.
You may ask yourself which method of generating project files should be preferred: generating project files via the build, or letting the IDE analyze your build code. My personal preference is to let the IDE do the heavy lifting. It’ll usually give you a good start. If you need fine-grained control over your configuration, you can bring in the Gradle IDE plugin support. You may have to be careful, though, not to directly override the existing configuration produced by the IDE. In practice, it sometimes takes a bit of playing around to get the desired result.
Many developers aren’t working for tool vendors—we usually work on Enterprise or open source applications that use Gradle as the build system. Why would we care about the tooling API? The tooling API is very versatile and can be applied to other use cases. Let’s explore one of them to see the API in action. In the following section, you’ll use the tooling API to implement integration testing by actively executing a build script. To verify its correct behavior, you can query for the runtime information available through the tooling API. When you integration-test a build script with the tooling API, you don’t have to use the ProjectBuilder class to emulate the creation of a project. The build script is tested from the end-user perspective and behaves as if you ran the gradle command from the console. Let’s look at an example.
Listing 10.16 shows the content of the test class CloudBeesSpec.groovy. It defines a single test method that uses the Gradle tooling API to execute the CloudBees task named cloudBeesAppInfo. Not only do you want to execute the task, you also want to make sure it behaves as expected. The task only produces command-line output, so you’ll need to parse the standard output stream to see if the correct application information is printed. This functionality is testable in a unit test because a Gradle task doesn’t allow for setting a mock object for the logger instance.
Gradle doesn’t leave you hanging. With the help of plugins, you can generate project files for various IDEs and editors. The generated project files contain the metadata needed to conveniently open a project in an IDE with the correct setup. We discussed how to use these plugins in the context of your To Do application to create project files for Eclipse, IntelliJ IDEA, and Sublime Text. This metadata is mainly derived from the default build script configuration but can be customized to fit individual needs.
Popular Java IDE vendors realized the need for first-class Gradle support. The IDEs SpringSource STS, IntelliJ IDEA, and NetBeans provide sufficient tooling for opening a Gradle project by pointing them to a build script. Once the project is opened in the tool, a developer is able to manage dependencies, use Gradle DSL code completion, and execute tasks from within the IDE.