2

I have a JVM application that I need to debug using breakpoints with a Gradle task (run and test as dependencies) within IntelliJ 2016.3.5.

There are various sources on how to accomplish debugging with Gradle and IntelliJ:

  1. Debug Gradle plugins with IntelliJ
  2. Using Intellij to set breakpoints in gradle project (most helpful one)
  3. https://youtrack.jetbrains.com/issue/IDEA-119551
  4. https://youtrack.jetbrains.com/issue/IDEA-86465
  5. https://youtrack.jetbrains.com/issue/IDEA-119494

However, these sources are either outdated or meant for another scenario. I do not want to debug the Gradle script but the JVM that runs the actual Java/Scala application. Moreover, the recent versions of IntelliJ use the Gradle Tooling API, which does not offer the option to turn off the daemon. A native support from JetBrains is only provided using the debugging button on the run and test tasks directly, but not if they are defined as dependencies from another task (e.g., check).

According to the sources, this is the way to go then:

run { // or test, doesn't matter
    jvmArgs "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"
    // xor, or both, doesn't seem to make any difference
    debug true
}

In any way, Gradle (or the JVM) will then start to listen on port 5005:

Imgur

Then, I have created a remote configuration with the following parameters:

Imgur

But when I start the IntelliJ remote debugging task, it fails:

Imgur

I have also tried using port 5006 and suspend=n without success. Before that, I tried using Gradle arguments in the IntelliJ-Gradle run task. Then, it indeed connected, but seemingly to the Gradle script and not the application JVM because it did not interrupt at the breakpoints. How to fix this?

Community
  • 1
  • 1
matfax
  • 634
  • 11
  • 17
  • Why you can not simply use Gradle Debug Configuration, e.g. using debug action from the gradle task context menu at gradle tool window? – Vladislav Soroka Mar 15 '17 at 15:23
  • Because, in this case, it actually debugs the Gradle script for me, but not the Java or Scala code. That means, breakpoints within the Java or Scala code will not do anything. – matfax Mar 15 '17 at 15:36
  • I've rechecked it, not even the Gradle script is debugged. – matfax Mar 15 '17 at 15:46
  • As you can see on my screenshot, it works for java applications. Could you share the project and steps to reproduce? – Vladislav Soroka Mar 16 '17 at 10:18
  • I've created a new empty project now to reproduce the issue and tried different settings in the Gradle script. My mistake was to initiate the run and test tasks via intermediate tasks (e.g., check for testing). But the debugging seems only to work if it is initiated directly on the regarding task (i.e., directly starting test or run with the debug option). I didn't expect Gradle or IntelliJ to distinguish the first task. – matfax Mar 16 '17 at 14:14

2 Answers2

2

Debugging of gradle tasks like 'test', 'run', actually all gradle tasks that implements JavaForkOptions interface, should work in IntelliJ since 2014 year

Vladislav Soroka
  • 146
  • 2
  • Strange, if I use the debug button, breakpoints are simply ignored. May you share which Gradle version you are using? – matfax Mar 15 '17 at 15:40
  • 1
    it almost doesn't matter which version to use, actually all versions since 1.9 should work. – Vladislav Soroka Mar 16 '17 at 10:12
  • could you share the project to illustrate the issue? – Vladislav Soroka Mar 16 '17 at 10:14
  • I've created a test project here: https://github.com/matfax/gradle-test Can you confirm that check doesn't work on your platform (contrary to run and test)? – matfax Mar 16 '17 at 14:25
  • 1
    yes, I can confirm, but the check task does not implement JavaForkOptions interface like run or test. Debugging of an arbitrary task which has been triggered by another task (like 'check' in this case) is not supported yet. And the workaround is to use explicitly gradle task you want to debug. – Vladislav Soroka Mar 21 '17 at 12:45
  • 1
    This limitation was fixed in IDEA 2018.2. It should be possible to debug almost all java processes started by Gradle tasks and breakpoints inside Gradle DSL blocks also should work. See details at https://blog.jetbrains.com/idea/2018/05/intellij-idea-2018-2-early-access-program-is-open/ – Vladislav Soroka Jul 24 '18 at 08:38
0

Meanwhile, I found the solution myself. If you have a similar issue, follow the approach mentioned above using the debug option.

test {
    debug true
}

But make sure that external connections are accepted in the settings after IntelliJ restarted:

Imgur

Imgur

Then, it connects to the correct JVM and interrupts at the breakpoints using the remote task:

Imgur

Imgur

If you restart IntelliJ, however, with the very same option (external connections) enabled, then the debugging task might fail due to a blocked port:

Imgur

So, for some reason, IntelliJ blocks that port after a restart but it is necessary to enable the setting for the debugging task to work. That's odd and I don't think it is intended to behave like that.

Anyways, if you disable the setting and restart, the port will be open again. Then, re-enable the setting, do not restart, just run the Gradle task, and the debugging task. It will work.

I hope this helps anyone else looking for an intermediate solution to debug JVM applications with Gradle and IntelliJ among the confusing and partially outdated answers out there. If anyone has a better or simpler suggestion, feel free to append your answer.

matfax
  • 634
  • 11
  • 17