Problems debugging plugin code in debugger

Old Forum Archive
1

I’m working on my first plugin, getting testing and debugging working before I write a lot of code. The plugin and tasks are working skeletons, and a separate project applying the plugin reports the task on “gradle tasks”, so that looks good so far.

I now want to step through the existing plugin code in the debugger. The advice on this seem scattered. The user guide has almost no information about this, and I think I see a discrepancy in what little is there. The only statement in the entire user guide that mentions debugger support is the following section:

23.13.2. Debugging > The test task provides a Test.getDebug() property that can be set to launch to make the JVM wait for a > debugger to attach to port 5005 before proceeding with test execution. > This can also be enabled at invocation time via the --debug-jvm task option (since Gradle 1.12).

When I run Gradle 2.3 with “–debug-jvm”, it says: “Unknown command-line option ‘–debug-jvm’.”

I also found a Gradle forum post that Peter responded to. I’m using that as a guide, but I’m still seeing weird results with no success.

I first turned off the daemon in ~/.gradle/gradle.properties and then killed the daemon process.

I set a breakpoint in my plugin’s “apply” method. I know it’s getting here because I just added a line that fixes a bug, and after installing the plugin the project using it doesn’t get the error anymore.

In my shell, I set GRADLE_OPTS to:

"-Dhttp.proxyHost=myproxyhost -Dhttp.proxyPort=myproxyport -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5006"

I then ran the following, with the following output:

% gradle tasks --no-daemon -Dorg.gradle.debug=true
Listening for transport dt_socket at address: 5006
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/2.3/userguide/gradle_daemon.html.

The statement about forking the JVM is curious.

I then connected to 5006 from Eclipse.

At this point both Gradle and Eclipse are contentedly waiting for something to happen.

What can I do here?

2

You don’t want to specify both GRADLE_OPTS and ‘-Dorg.gradle.debug=true’. Simply adding the command line property is enough, and will start listening on port 5005. Also, you don’t necessarily need to disable to the build daemon. If you don’t the command line option will debug the build daemon JVM, which is what you want. Also, one advantage of debugging the daemon is you don’t have to continually reattach to the debug process, since the daemon is persistent across multiple builds.

3

Perfect. Thanks.

4

Has there been any thought of making this a standard command-line argument, so someone doesn’t have to remember this property when they have to do this?

Also, is the port number overriddable? I don’t need to, but I would imagine someone eventually will want that.

5

The port isn’t overridable via the ‘org.gradle.debug’ property however you could specify whatever debug arguments you wanted with the ‘GRADLE_OPTS’ environment variable.

6

Is this functionality technically supported yet? A year ago, Peter said it was not: http://forums.gradle.org/gradle/topics/how_do_you_attach_a_debugger_to_gradle_so_that_i_can_debug_it_running_a_task .

So you’re saying that setting “org.gradle.debug=true” sets some default “-Xdebug” arguments, and whatever goes in GRADLE_OPTS will override it?

7

I’m not certain that is the case. My suggestion is that if you don’t want to use the default port you should use ‘GRADLE_OPTS’ instead, rather than defining both.