Skip to content

Contributing & Debugging

Jump to bottom
Tony Robalik edited this page Feb 8, 2021 · 2 revisions

While the CONTRIBUTING.md doc contains basic information, for those who want to dig deeper, this page will give some advice.

Debugging

One of the most important skills when working on a gradle plugin is debugging. There are two contexts in which you’d want to debug:

  1. Debugging behavior in a real project with the plugin added as an included build

  2. Debugging behavior in a functional test

Setting up a composite build

Composite builds are a really great way to iterate on a gradle plugin, and saves you the trouble of publishing to maven local from the plugin project and then consuming this published snapshot in another project. Setting this up is very easy.

settings.gradle
includeBuild("relative/path/to/dependency-analysis-android-gradle-plugin")
root build.gradle
plugins {
  id 'com.autonomousapps.dependency-analysis'
}

For this to work, you must use the plugins {} block, and a version is not required.

Once you’ve done this, sync your IDE (I use IntelliJ IDEA CE), and you’ll actually see the plugin code right in the IDE. This makes iterating very easy.

Debugging a composite build

Set breakpoints in the plugin code like you normally would. Then run a build from the command line:

$ ./gradlew buildHealth -Dorg.gradle.debug=true

It will probably start a new daemon, and then it will look like it’s hanging. You now have to create a new run configuration in IDEA. Click the Edit configurations button, and then the + button to add a configuration, and then choose the Remote template. Name this configuration something like "Debug Gradle" and click OK. Now, click the debug button and IDEA will connect to the gradle build you started from the command line. You should see it hitting your breakpoints.

Tip
 if it seems like your breakpoints aren’t being hit, and these are in task actions, it might be that the tasks are up to date or coming from the build cache (if build cache is enabled). In this case, run a clean and then use --no-build-cache when you run your debug build: 
$ ./gradlew clean && ./gradlew buildHealth --no-build-cache -Dorg.gradle.debug=true

Another possibility is that gradle is just broken somehow, in which case

$ ./gradlew --stop

and try again.

Debugging a functional test

Functional tests are executed as follows

$ ./gradlew functionalTest

or optionally (and recommended for iterating more quickly)

$ ./gradlew fT -DfuncTest.quick

(where fT is gradle shorthand for functionalTest)

and can be debugged in a similar fashion to the composite build debugging discussed above. There are important differences, however.

First, execute the build

$ ./gradlew fT -DfuncTest.quick --debug-jvm

Take note that the debug flag is different in this context. This has to do with the fact that TestKit-driven tests run test builds in a separate JVM, distinct from the Gradle process driving the build.

The build will run for a bit, but once it finishes compilation and gets to where it wants to execute the functionalTest task, it will seem to hang. Now, go to your IDE and click the debug button for your Debug Gradle run config.

Clone this wiki locally