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.
Related
IntelliJ IDEA 2021.1 and 2021.2 leaves the Gradle Daemon running when I exit the program. I would like to know if there is a way to momentarily stop or restart the Gradle Daemon from within IntelliJ without exiting. Gradle has a lock on files that doesn't go away when simply closing IntelliJ. The only way to get it to release the lock is to run gradle --stop from the version of Gradle that is currently running. The approaches I've found so far are far less than ideal. I'll share them in case they help anyone else, but I'm hoping there's a better way.
If I manually browse to my User Home.gradle\wrapper\dists\gradle-x.y.z-all<hash>\gradle-x.y.z\bin for the version of Gradle that I know IntelliJ is using, then I can manually run that gradle command with --stop flag and it will stop the daemon. So, yeah I guess I could create a batch script for this, but the fact that it is stored in such a buried directory involving some sort of hash code, I don't really want to have to change this script for different systems.
In InteliJ IDEA, If I click the "elephant" looking button at the top of the gradle menu called "Execute Gradle Task" it brings up a command line that starts with "gradle", but it only accepts established task names, it doesn't accept "gradle --stop". It gives the error Unknown command-line option '--stop'.
As a less than ideal work around, I have copied the gradle-x.y.z folder from near the end of that path to c:\Gradle\ and I have added that version's bin folder to the PATH environment variable. So, at least, I can open up a command prompt and run gradle --stop for now. This becomes problematic when I want my default / command line accessible gradle version to be different from the project I am working on. Yeah I could create a bunch of custom batch scripts that point to all different versions. That doesn't sound like fun. I have a hard time believing that I can't do something within IntelliJ to get the currently running gradle daemon to shutdown.
IDE does not kill Gradle daemon, because this demon can be reused by another build, including when doing a build from the command line.
There is an action Show Gradle Daemons (you can call it from Help | Find Action action):
It will show you the list of Gradle daemons with the ability to stop them:
I have a gradle task (type - exec). In this task I start a WildFly server using a standart bat file (standalone.bat). The war file is already in deployments beforehand, so the server starts up and everything works fine.
The problem appears when I need to debug the actual application on the server. Running the gradle task in a debug mode doesn't help, as it can only debug the actual gradle task itself and not the application that it starts.
I know, there is a solution to this problem using an additional configuration that would allow me to debug a remote java application. However, the goal for me right now is to move eveything onto gradle tasks and not have any configurations set up in my IDE.
I need to be able to run a gradle exec task that would start up my server and than to debug whatever application it deploys. Is there a way to do this? Thank you in advance.
Note: I've never used Wildfly
Ultimately you'll want to edit standalone.bat so that you include an additional arguments to the java.exe invocation. Take a look inside standalone.bat many applications include a line commented out that you can uncomment to enable debugging.
Eg sample argument to add to the java.exe call
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044
You may wish to take a copy of standalone.bat which you call standalone-debug.bat which you invoke via gradle
Every time I execute a gradle command on Mac I get a message saying:
"This build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.10/userguide/gradle_daemon.html"
I've created a gradle.properties file with the line org.gradle.daemon=true as mentioned in the web page given in the message. However no matter what I do, I still continue to get that message.
If I execute the command
gradle --daemon
then it executes successfully, but still next time I do something I get that message about it could be faster and builds are just as slow as before I started the daemon.
My installation directory is no /Users/username as in gradle_daemon.html as I'm falling a Udacity course (https://www.udacity.com/course/viewer#!/c-ud867/) and they recommend installing it to /usr/local/gradle
How can I actually get the gradle dameon to work and get rid of that could be faster message?
(Using Gradle version 2.10)
just put
org.gradle.daemon=true
in the ~/.gradle/gradle.properties file. Then each build on your machine will use the gradle wrapper and the message dissapears.
The page doesn't say anywhere that gradle must be installed in /Users/username. It says that this directory is your home directory, and that's where the .gradle/gradle.properties file must be located. The place where gradle is installed is irrelevant.
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.
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.