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:
Related
We wired https://github.com/sherter/google-java-format-gradle-plugin into our project per the readme.
We also wired in a pre-commit hook to run the plugin before committing, which ensures that all of the code in a changelist is formatted before pushing it, which avoids errors in Jenkins when we run the verGJF task.
But we have to keep remembering to run goJF locally before running ./gradlew build, or the build fails with formatting errors.
We worked around this by adding the https://plugins.jetbrains.com/plugin/8527-google-java-format and https://plugins.jetbrains.com/plugin/7642-save-actions plugins for IntelliJ, enabling the google-java-format plugin, and configuring the save-actions plugin to format on save.
But that's a lot of extra configuration a developer has to remember to go through, plus it means they can't format code the way they want while working on it, and only have it be reformatted at the point of build or commit.
We'd prefer an all-Gradle solution, so that the goJF task is run before the build task (and before the verGJF task, which is already bound to the build task by the google-java-format Gradle plugin).
We couldn't figure out how to do that. Does someone else know?
It sounds like you want to essentially always ensure that the code is properly formatted before the verifyGoogleJavaFormat task is run (and could complain). In that case, I’d simply make the googleJavaFormat task a dependency of the verifyGoogleJavaFormat task. In your build.gradle file, after you have applied the google-java-format plugin, simply add the following:
verifyGoogleJavaFormat.dependsOn(tasks.googleJavaFormat)
Alternatively, if you really only want to run the code formatter when the build task is run (as opposed to when the verifyGoogleJavaFormat task is run only), you could add this instead:
build.dependsOn(tasks.googleJavaFormat)
verifyGoogleJavaFormat.mustRunAfter(tasks.googleJavaFormat)
While running an application processResources task of gardle(Copies resources from their source to their target directory, potentially processing them) tries to delete the git.properties file in build folder,
However, the same file is being created at run time while building an application in some task before proceeResources, but getting locked by gradle daemon so the task proceeResources can't work on it and ends with an error,
java.io.IOException: Unable to delete file: {projectWebappPath}\build\resources\main\git.properties
> Unable to delete file: {projectWebappPath}\build\resources\main\git.properties
In SysinternalSuite, if I run the program procExp.exe on windows 7, I can see the file is locked by gradle daemon.
Question is :-
How do I handle this situation, I have no clue, I was trying with disabling daemon but it is not recommended. Which didnt resolve issue either.
I have started getting this issue 3 days before, earlier it was working fine, I dont understand what could be the reason and if I try to exclude processResources task while building for time being, it has another impacts so cant really do that.
I'm using windows 7,64 bit OS, trying to run gradlew build on intellij terminal.
Any help or clue would be appreciated.
Thanks in advance.
on Windows, this might be something alike:
taskkill /F /IM gradlew.bat /T
or whatever name the gradle daemon uses there.
you could also kill the stalled instance with the GUI task-manager.
generally, it can only be the last one instance of the daemon, which could have locked the file. also look for *.lock files, which might be impossible to delete when building under various user accounts.
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.
I'm setting up Jenkins for the first time and running into an issue where Jenkins does not appear to even attempt to execute the Ant task I've specified.
I've defined my JDK and Ant installations under Manage Jenkins.
I've setup my Job to Invoke Ant using the Targets 'war-all'
Whether I force a build or wait for it to naturally execute after the next commit, there is nothing in the Build Console Output about attempting to execute the ant task.
Here is a sample Console Output:
Any ideas as to why it might not be executing would be appreciated. Also tips on how I can find more logging from Jenkins which might provide clues as to why it is not executing would be helpful. I'm not sure what Logger I might specify or even then where the logging information is written on the file system.
The problem was that I was selecting "Build multi-configuration project" as the type of my job. When I select "Build a free-style software project" as my job type the Ant task will execute after the SVN update.
Looks like your svn doesn't see any changes and therefor is not re-building the module.
Try deleting the workspace and re-trigger the build, or change the check-out strategy to 'Always check out a fresh copy'.
I faced the same problem when upgraded to 1.417 from 1.413.
The combobox "Ant version" disappeared from "Invoke ant" build step. It should be here.
I just downgraded to 1.413 and continue to work.
So, the answer is - you should specify "Ant version" in project settings. But you cannot do it in 1.417.
It seems like Jenkins doesn't like when you create a job before configuring JDK. If that happens, job will never work properly. So, for me the solution was:
Delete job.
Configure JDK
Re-create job.
Probably the same problem may arise when job's JDK is deleted.
In my case,ant default target was not being picked up from build.xml so I had to explicitly mention the target in jenkins option.
I resolved this by changing the jdk to default and then again switched to what was set earlier.This is a workaround but not sure how this resolved.
I have a shell script that runs lcov (test coverage) on an iOS project that I have Hudson. Hudson's copy of this project is derived from a Git repository. The way that I have set up now is that whenever the repo is updated or if someone manually builds the project in Hudson, Hudson would automatically run the app, and then run my shell script after the build is done. lcov can only be run after the app is not only built, but automatically run with some functional test tools. So, I cannot run the shell script as part of the build process, through XCode. It must be run after the app finishes building and running.
However, I would like to use this project in multiple Hudson jobs. Unfortunately, in each Hudson job, the iOS project is named differently. I would like to refer to the build path with some sort of environmental variable, but I don't know how to. Does anyone have any tips as to how to find that?
If I understand you correctly this is really a Hudson question. You can set "global variables" in your Hudson config and then invoke shell scripts, batch files, ant builds etc. You can also set them dynamically on each invocation of your Hudson job. Not sure exactly how to help you in your specific environment without more info.