Reputation: 6810
Nine times out of ten when I run mvn clean on my projects I experience a build error. I have to execute mvn clean multiple times until the build error goes away. Does anyone else experience this? Is there any way to fix this within Maven? If not, how do you get around it? I wrote a bat file that deletes the target folders and that works well, but it's not practical when you are working on multiple projects. I am using Maven 2.2.1.
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to delete directory: C:\Documents and Settings\user\My Documents\software-developm
ent\a\b\c\application-domain\target. Reason: Unable to delete directory C:\Documen
ts and Settings\user\My Documents\software-development\a\b\c\application-domai
n\target\classes\com\a\b
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6 seconds
[INFO] Finished at: Fri Oct 23 15:22:48 EDT 2009
[INFO] Final Memory: 11M/254M
[INFO] ------------------------------------------------------------------------
Upvotes: 42
Views: 51153
Reputation: 6831
Following are my findings -
Apart from IDE holding on to the jar, at times you will have some java process which could cause this as well. Lookup for any "java.exe" / "javaw.exe" process in task manager and kill it.
It helped me resolve this at times.
Upvotes: 6
Reputation: 13235
Windows Indexing Service, application server or IDE holding the JAR file is the root cause. Best solution is to disable Windows Search Service or exclude JAR files from indexing.
Another (imperfect) option mvn clean || mvn clean
. Double pipe symbol runs second command only if first one fails.
See Releasing Windows file share locks for details on how to find and remove Windows write locks (it advises to use ProcessExplorer or Unlocker).
Upvotes: 2
Reputation: 1
you should close all the files in target ,for me i use M2eclipse directly is better you can also try mvn clean -Dmaven.clean.failOnError=false
Upvotes: 0
Reputation: 2173
In my case, there is a java process which is executing the surefirebooter.jar which is the plugin to do the maven JUnit test. So you can simply open the task manager and kill the java process.
Upvotes: 1
Reputation: 1053
If you're using IntelliJ, you can pass an additional parameter in the Maven Runner settings:
-Dmaven.clean.failOnError=false
Set it here, in the VM options:
References: http://www.jetbrains.com/idea/webhelp/maven-runner.html http://maven.apache.org/plugins/maven-clean-plugin/faq.html
Upvotes: 2
Reputation: 181
The application which you are running should be stopped. Looks like the app is still running, while you are trying to clean the app.
Upvotes: -1
Reputation: 2308
If you don't want to change Windows Indexing settings, you can simply pause it, too.
Upvotes: 0
Reputation: 4801
I had the same problem. I closed eclipse and looked at the running processes in task manager and seen one called 'Java.exe' which is not usually running so I ended it and then run 'mvn clean' again. It should delete the file properly and work correctly.
Upvotes: 1
Reputation: 1159
This is mostly caused by Windows Indexing. Excluding target folders or .jar extention from indexing will fix the problem. My best practice is excluding .jar extention.
To exclude target files:
To excluse all .jar files:
Upvotes: 22
Reputation: 7768
The solution is restarting windows 7 .It helps to release the resources.
Upvotes: -5
Reputation: 194
What I have found is that Java development with Maven on Window 7 struggles when the source code is on C drive. Moving my code to another drive works. Even a logical drive will work, the drive doesn't necessarily need to be a different physical hard drive.
Upvotes: 0
Reputation: 9446
The problem is eclipse is constantly reading the directories and artifacts in your maven project and inevitably has one of them open when you are cleaning.
The best approach is to run maven clean from the eclipse plugin (I use m2eclipse and this seems to work well).
Another approach that sort of works is to run mvn clean
with the maven.clean.failOnError
flag set to false
. If you run it twice usually that is enough to make everything work properly, e.g.
mvn clean -Dmaven.clean.failOnError=false && mvn clean -Dmaven.clean.failOnError=false
You will probably want to turn off eclipse's "Build automatically" from the project menu while you do that.
Upvotes: 12
Reputation: 657308
I had the same problem with builds run from Hudson.
Using handle.exe (from Sysinternals) I found out that a java.exe task has an active filehandle to the generated jar file.
If I kill this task the next build succeds. But the next build after this successful build fails again with the same error.
Even if the build task succeeds, it seems not to terminate properly and keeps files open.
I'm a beginner with Hudson and I didn't have this problem at first. Then I played with some plugins and later this problem come up and was reproduceable.
I deactivated almost all plugins (kept only some essential ones like subversion and sonar) and now the problem seems to be solved.
Hope this helps a bit ...
Upvotes: 1
Reputation: 84038
I'm guessing you are opening files in a text editor or leaving a shell open on a directory in target. If some process has a lock on a file or folder Windows won't let you delete it.
If you run a tool like wholockme you'll be able to see what process is locking the file.
Upvotes: 2
Reputation: 9415
That's because you block target directory (open a file or enter into (sub)directory of target dir, or any other process/app uses file from this dir). If windows delete command also complains it's not maven fault.
Upvotes: 0
Reputation: 22914
It may be that your IDE or some other process is holding on to the the "target" folder and preventing maven from deleting it.
Upvotes: 41
Reputation: 44321
Often you run into this problem when on Windows because Windows doesn't (ordinarily) allow you to delete a file which is in use. Aside from (painfully) going through all your Maven configuration, your best bet is just not to build on Windows (e.g. use a Linux/Solaris/whatever VM).
Upvotes: 3