I'm trying to debug some unit tests I've written but the gradle daemon seems to always launch, ignoring any options I've set.
Using Mac OS X 10.9.5, Java 1.7, Gradle 2.2.1 and robolectric-gradle-plugin 0.14.1
Launching gradle with:
GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5006"
./gradlew test --no-daemon -Dorg.gradle.debug=true
causes the following line to appear
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/2.2.1/userguid....
I've also tried setting the -Xdebug and Xrunjdwp as jvmArgs in build.gradle.
Nothing else happens but if I add -d and rerun, it turns out that the daemon has launched and is waiting on port 5005 for a debugger: http://pastebin.com/TqaXubmr
Finally, if I then launch a debugger attaching to port 5005 the tests run but none of the breakpoints are hit.
The gradle.properties is empty, I haven't set org.gradle.jvmargs.
You might have configure memory settings in your gradle.properties? these can force gradle to launch a new jvm as these settings cannot be applied dynamically.
Keep in mind that unit tests are always executed in a separate jvm. The easiest way to debug tests executed by gradle is to run
>gradle :test --debug-jvm
this will automatically configure your test task to run with debug enabled.
Related
I got java cucumber + serenity project in Intellij
I configured the maven run configure:
Working directory: xxxxx
Command line: clean verify "xxxxx"
The run configure works fine before, I can use it run test as well as fire up the debug mode.
However, one of sudden, I cannot run the debug mode anymore. Even though I clicked the debugged button (green little bug) it never stops at the break point.
It still stops if I added break point to java.lang Object class, but it never stops at any break point from actual test methods, very weird...any one can help? Thanks
Surefire starts a new jvm to run tests (a fork). You are debugging the jvm that starts the second jvm, not the jvm that runs the tests.
Either change the fork mode or attach a debugger to the forked jvm.
http://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html
On cmd, all gradle commands like "gradlew, gradlew -version, gradlew build" get stuck with one line
Listening for transport dt_socket at address:5006
Most probably, your Gradle runs in debug mode. Debug can be turned on in different ways. Check the value of GRADLE_OPTS environment variable and org.gradle.jvmargs Java system property. Latter can be set in different places: on the project level (in gradle.properties in project root) or in global config (~/.gradle/gradle.properties).
Setting suspend to n will allow you to both run the process in debug mode and do not wait for the debugger.
With gradle run -t my java application restarts nicely after exit whenever a src file changed. But can I use Gradle to terminate a running app and restart it?
I can see using -d that Gradle detects the change while my app is running.
[DEBUG] [org.gradle.internal.filewatch.jdk7.WatchServiceFileWatcherBacking] Received file system event: FileWatcherEvent{type=MODIFY, file=/usr/src/app/src/main/java/App.java}
[DEBUG] [org.gradle.internal.filewatch.jdk7.WatchServiceRegistrar] Calling onChange with event FileWatcherEvent{type=MODIFY, file=/usr/src/app/src/main/java/App.java}
But as documented restart requires that "the build task and its dependencies complete without error".
I'm running in Docker, hence the IDE's support for compile during run can't be used. For Node.js I use Nodemon for this kind of development setup.
I no longer think that this would make Java development any more efficient. See https://discuss.gradle.org/t/how-to-restart-a-run-in-continuous-mode/23221/11.
I'm running unit tests from the gradle command line (because running them from IntelliJ was causing problems for some reason.)
So I'd like to turn on a debug port for remote debugging from the unit test. How can I do that? Is there a way to send the -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y into the unit test itself? I'm using Gradle daemon mode so I'm not sure how that all works and can't find any documentation about it.
Actually it turned out that there's no need to set the jvmArgs manually. Instead you just need to invoke (docs):
gradle someTestTask --debug-jvm
and it will stop execution and wait for debugger connection. Now when this process hangs, go to IntelliJ, Eclipse (or other IDE) and set up an remote debugging configuration (remember to set source module - red arrow):
After it's set, run the debugger and you're done. Breakpoints may be set in IntelliJ directly.
Previous answer below:
test {
jvmArgs '-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y'
}
How do I determine why my Gradle Daemon died? The only message I get isL
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
This occurs in an active build. Several steps will finish and a step will appear to be active and then the build fails.
This began after moving our memory args (Xmx Xms PermGen) from a shell script that called gradlew to gradle.properties and calling gradlew directly.
build.sh
export GRADLE_OPTS="\"-Xmx1024m\" \"-Xms256m\" \"-XX:MaxPermSize=256m\""
export JAVA_HOME="/usr/local/java/jdk1.6"
exec ./gradlew "$#"
Addition to gradle.properties
org.gradle.java.home=/usr/local/java/jdk1.6/
org.gradle.jvmargs=-Xmx1024m -Xms256m -XX:MaxPermSize=256m
After this change Gradle warns:
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/2.2.1/userguide/gradle_daemon.html
And even though we don't ask it to, the build is running in a daemon, which ultimately fails.
Gradle build daemon disappeared unexpectedly most frequently occurs when something else kills the long-running Gradle Daemon process and the client process (the Daemon uses local TCP connections to communicate) tries to send a message and gets no response.
For example, running gradle --stop or killall java while a build is occurring will reproduce this problem.