This is a small post for those who’s primary IDE is Eclipse for developing Grails 3 apps or plugins — and are still wondering how to debug their application.
First of all, to clarify: there’s no “Grails” debugging, it’s just Spring Boot and Gradle these days, with Grails 3. Any way to debug these kind of applications allows you to debug a Grails 3 application.
There’s lots of SO posts and Google hits about this subject, so I’m creating this post also as a short “simplest solution” summary for myself and for others.
As of a few Eclipse versions, the Eclipse Buildship plugin is shipped along, in the regular Java bundle at least, which allows me to do a lot with Gradle, which underpins Grails 3, from inside the IDE. Next to executing any Gradle task, such as bootRun on my Grails 3 apps, it would be really useful if I could also use Buildship for debugging too.
Well, at the moment of writing there’s still no such thing: already since 2015 debugging a webapp with Buildship has been on the roadmap. You can start Gradle with it, but you can not debug it yet.
So, a simple way of debugging is: Eclipse’s remote Java application debug capability + Gradle in debug mode.
Tried with a fresh Grails 3.2.7 hello-world application. (On MacOS using Oracle JDK 8 with Eclipse Oygen (4.7) — but that’s less important)
Just 2 steps:
- Start up the JVM in debug mode with
./gradlew bootRun --debug-jvm - In Eclipse create a remote Java application launch configuration connecting to earlier JVM
Using gradle bootRun --no-daemon -Dorg.gradle.debug=true did allow Eclipse to connect in debug mode, but Eclipse wouldn’t halt at any breakpoints.
By example
Assume a clean Grails 3.2.7 application.
Add a line in BootStrap.groovy and set a breakpoint on it:
Start the application in debug mode with the Gradle wrapper (or external Gradle) with the --debug-jvm parameter.
localhost:hello-world tvinke$ ./gradlew bootRun --debug-jvm Starting a Gradle Daemon (subsequent builds will be faster) :compileJava NO-SOURCE :compileGroovy :buildProperties UP-TO-DATE :processResources :classes :findMainClass :bootRun objc[12520]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java (0x1041d24c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10429a4e0). One of the two will be used. Which one is undefined. Listening for transport dt_socket at address: 5005 > Building 85% > :bootRun
At his point the application halts, stating it listens at port 5005, and it will not continue (by design) until a debugger is attached.
Create in Eclipse a debug configuration (under Debug Configuration add a Remote Java Application entry) — leaving the default on localhost, but change the port to 5005.
Attach Eclipse to the waiting JVM and start debugging with the Debug button.
The application continues starting up. And actually halts on our breakpoint.
Future support for debugging with Eclipse Buildship
Eclipse Oxygen is currently shipped with Buildship version 2.0. When does Buildship get an update which makes debugging Gradle from within the IDE possible? In the Bugzilla ticket, which has been moved to the newer #249 GitHub issue, there are no plans for getting a “Debug As…” option in Eclipse, just as with regular Java applications.
As one of the developers is saying:
Adding convenience for this would of course be great, but there are other things that are more important, like composite build support, Kotlin support, having the correct runtime classpath etc.
Any other ways within Eclipse?
Some have tried to install Spring IDE Core in Eclipse Mars from the Spring update site, and debug a Grails application as a Spring Boot App configuration — but I haven’t been able to do this under Eclipse Oxygen anymore. Missing/failing dependency stops it all.
Of course, there are probably other ways with Eclipse (using other Gradle integrations perhaps) and if you find a way, please let me know!
| Reference: | Debugging Grails 3, Spring Boot or Gradle with Eclipse from our JCG partner Ted Vinke at the Ted Vinke’s Blog blog. |
