we have a plugin that is not behaving per expectation. i have figured out that I can ./gradlew myBrokenTask -Dorg.gradle.debug=true to make the debugger wait for a connection. further, i’ve successfully had intellij attach to that debugger. however, some SO posts have told me i cannot debug DSL content, but rather only java-ish content within.
i am skeptical to believe that the only way to debug my scripts is to drop logger or println statements everywhere. am i mistaken?
further, that dependency lives somewhere outside of my project directory structure, probably in my ~/.gradle cache somewhere, yes? what would be the strategy for getting a breakpoint tagged over there? albeit, it is a .jar file…
what are the best debugging practices out there? the gradle docs don’t mention much in this regard.
No, that is correct. It is an unfortunate side effect of how Gradle compiles the classes for build scripts. A workaround is to move the bulk of your script into a plugin under buildSrc - see slide 11 (Copy/paste to a plugin) in Gradle Build Evolution - Google Slides - once it becomes a precompiled plugin you can put breakpoints.
Just open the class in your IDE and put a breakpoint as long as the line numbers and classnames match the source code, it doesn’t matter how it was included in the classpath.
maybe you can assist with another, related question. the package where my plugin lives indeed contains many plugins. the build test cycle is rather long. there many many tests for the variety of plugins living in src/test/groovy/com/company-name/gradle/<plugin-name>. i can’t figure out how to just run the tests for one of those plugins (e.g. MyPluginTest.groovy).
if i do a groovy /path/to/test.groovy, it fails unable to resolve some things. however, ./gradlew uploadArtifacts runs the test, and it goes just fine.
