Gradle Improvements in IntelliJ IDEA 2018.2
In this post we’re going to look at new features in IntelliJ IDEA 2018.2 for Gradle support, but since we’ve not talked about updates to Gradle support for a while, we’ll also mention some of the other Gradle features that made it into recent releases.
Firstly it’s worth mentioning that importing Gradle projects is now significantly faster in IntelliJ IDEA 2018.2. Now that good news is out of the way, let’s look at the other features.
Debugging Gradle Scripts
IntelliJ IDEA 2018.2 has improved debugging for Gradle build files. It’s now possible to set a breakpoint inside a DSL block and see the state at that point in time. This makes it much easier to understand what’s happening at various points during the build.
Debugging Gradle tasks has been significantly improved – the debugger can connect to the Gradle daemon or to any Java process started by a Gradle task that implements JavaForkOptions.
Support for Custom Plugins
If your project has a buildSrc directory containing custom plugins, you’ll see that IntelliJ IDEA 2018.2 has automatically discovered this directory and now provides better integration between this code and your Gradle build files. For example, you can find usages of a plugin in your build, and navigate to the declaration of a custom plugin.
Gradle and the Touch Bar
If you’re using a MacBook with Touch Bar, you’ll notice that when you focus on the Gradle tool window, the Touch Bar is updated with the refresh button, letting you easily refresh all your Gradle projects.
Calculating Test Coverage with the Gradle Test Runner
Since we’re talking about features for Gradle in IntelliJ IDEA, we thought we’d share some things that have been around for a few versions now but haven’t been fully covered before. The first of these is the ability to find test coverage when using the Gradle Test Runner.
If you’re using Gradle as your build tool, you’ll know that some time ago IntelliJ IDEA introduced the ability to run your tests with either the IDE test runner or the Gradle test runner.
This was particularly useful if the Gradle build had some sort of setup or settings that were needed for running the tests, so you didn’t have to duplicate this in the IDE.
IntelliJ IDEA 2017.3 has extended this ability so that now you can choose to use the IDE test runner or the Gradle test runner when calculating which classes are covered by the tests and by how much.
If you choose to use the Gradle test runner for test coverage, when the tests are finished you see the familiar Gradle output of the test run and the coverage results as well.
IntelliJ IDEA is always evolving to make it easier to work with tools like Gradle. IntelliJ IDEA 2018.2 makes working with build files more intuitive, and makes it easier to debug your build.
Subscribe to IntelliJ IDEA Blog updates
