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.
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 been trying to build my Java web application using gradle. Everything work fine in the local drive and the build goes through as expected. However, when I switch to using the clearcase MVFS File system (G:), the build seems to behave erratically. From the windows 10 command line, if I change directory to the G:\ drive location, and execute "gradle war", it works fine the first time. After that, I run the same command again - the already created war file gets deleted and the classes are removed. It's bizarre. I did the following and still the behavior is the same.
disabled daemon
disabled file watching
Its the same behavior with Gradle 7 and gradle 6.8.
When I delete the .gradle folder, everything works fine again.
So - Does gradle not support the NFS and MVFS File System ? What is the solution to this problem ? Any help is appreciated.
Does gradle not support the NFS and MVFS File System ?
That is why I proposed in 2018 to use gradle only in snapshot views.
Especially considering a "gradle --no-daemon build" does defeat the purpose of having the daemon at all.
A build is better served in a local filesystem than a mounted one (MVFS dynamic views) which relies on where your view server is.
Same configuration is working with window 10. but when i tried same configuration run with ubuntu, its showing an error.
error message while running with jenkins
The clean plugin cannot delete the named folder. Make sure the Jenkins has the right to delete the folder and that it is not locked in some other way.
By the way: Copy the text of your error into the question, don't make a bad photo.
Some process has hold of the file /home/xelpmoc-06/Documents/Doc/zerodha/target/classes/LoginZerodha/Zerodha/App.class.
Java process or Eclipse or some other program is doing some job with it. So that's why its showing that error. So please kill Java Process or restart Eclipse. May be your jenkins build failure, also can cause this to happen. So if nothing works out please restart your jenkins itself.
Here I am attaching a link that may be helpful to you. Please go through this. Hope this helps.
I am using IntelliJ Idea 2017.3 and on any Gradle project (even for simple 'hello world' from GitHub) I always got next error:
"Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/3.5-rc-2/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Error: Could not find or load main class 1.8"
Meanwhile, if I run an application with Gradle wrapper (gradlew.bat in my case) everything works perfectly. For me it looks like misconfiguration issue, but I cannot find what I am doing wrongly in Idea configuration or any other place. I appreciate any help with it or clue where to dig.
The issue was resolved and I would like to share this knowledge with all those who encounter a similar problem.
In my case, I had to delete two configuration files gradle.experimental.xml and gradle.settings.xml from IDEA configuration directory %IDEA_HOME%\config\options. I suppose they were created at the time when I installed Gradle globally on my PC. Somehow these settings were persisted, even after I removed globally installed Gradle and started to use Gradle's wrapper.
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.