Reputation: 666
When running certain build.xml targets, the clean has a hit or miss on deleting the ivy jar directory. The "locked" files are by eclipse, using explorer on the directory or rerunning ant from eclipse refuses to delete it until restart of eclipse. This is very time consuming.
Some reason eclipse is holding on to this files after running ant build/clean.
It's not all the projects and only at certain times for unknown reasons.
There is this existing discussion. Eclipse won't delete files
but it doesn't answer the question for me about how to get eclipse to run ant without having to restart every time.
Is there a way to use eclipse -console to see the file handles what is holding it? or does somebody know a root cause to why eclipse/ant/ivy wont let go of these targets after a build or two (1st time after a fresh start of Eclipse works fine) but then some subsequent ant build after that it becomes unhappy.
In my case it is eclipse which is locking the file for sure. Restarting Eclipse is not a solution. Otherwise, I'll just go back to a command line window. I've tried setting the run in same jvm, and all sorts of settings.
Do I need to debug the eclipse plugins? Is there an easier way to find out what's not release the lock within Eclipse and it's plugins? This is my first time ever to see this and I suspect it's IVY causing it.
Running juno, ivy, spring, ant and have the problem when run-as Ant Build from Eclipse that clean is unable to delete the lib/build directory of the artifacts.
eclipse.buildId=M20130204-1200
java.version=1.6.0_43
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -product org.eclipse.epp.package.jee.product
Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product
!ENTRY org.apache.ivyde.eclipse 1 0 2013-06-04 11:36:50.344
!MESSAGE starting IvyDE plugin
ant target:
<target name="clean-retrieved" >
<delete includeemptydirs="true" >
<fileset dir="${basedir}">
<include name="lib/**" />
</fileset>
</delete>
</target>
ERROR:
clean-retrieved:
BUILD FAILED
C:\scripts\common-build-targets.xml:238: Unable to delete file C:\scripts\lib\build\annotations-1.3.8.jar <<just first jar file in directory..
Upvotes: 6
Views: 16401
Reputation: 4128
I've started to see this problem with more recent Eclipse updates. It turns out that the ant plugin would lock all the jar files referenced in build files even before the tasks are executed. To disable this strange "feature" I did the following and it made the problem go away:
Upvotes: 1
Reputation: 2976
I had that problem too. It was caused because of a denied permission for a folder. I couldn't switch owner of the folder. What solved the problem was to install Lockhunter unlock the folder, deleting and recreating it.
Upvotes: 0
Reputation: 1246
I'm going to chip in here (I know this is an old post)
My Eclipse/Ant combo was working fine but then I created a new workspace which looked ok but refused to remove the dist/*jars
during a clean.
I tried removing them via Windows Explorer which claimed that they were already open in Eclipse.
An Eclipse restart worked but was time consuming.
My solution - I created a new workspace and re-imported my projects to it.
My guess - some corruption within my original workspace.
Upvotes: 0
Reputation: 1
This seems to be a problem with the ant plugin. In my case, when the plugin parses the build.xml file, it opens file handles to all jars mentioned in the classpath of my taskdef elements. As soon as an action causes the ant plugin to parse the build.xml file it acquires file handles to these jars and won't release them until eclipse is closed. I consider this a bug in the ant plugin -- it should only hold open file handles while the target is being run.
I have found no work-around for this problem other than reverting to command line usage of ant instead of the eclipse plugin. The entire build could be restructured to put duplicate copies of these jars elsewhere and update the taskdef targets, but that's a serious hack. People on the team with mac or linux don't see this because those allow you to delete a file that has an open file handle. Can debate the merits of that elsewhere.
Upvotes: 0
Reputation: 1
Execute below from command line
c:\path_to_eclipse\eclipse.exe -clean
Upvotes: 0
Reputation: 1935
This occurs when a process is using said file. I've had this issue happen usually when the program that uses said jar is still running. Verify that you aren't still running your program in eclipse. The easiest way to see that visually is to see this:
That red square (stop button) being enabled means that your program is still running. If you press that, you'd be stopping your process. However, if your program wasn't running it'd look something like this:
Since the "stop" button isn't enabled, it means the program isn't running. However, it's possible that there are other processes also running, other than the one shown at the time. To see that, you can see a "computer screen" icon on this next screenshot:
That computer screen being enabled signifies that you have ran multiple programs/processes. Clicking on the down arrow lets you change to other programs. Check to see if those are running, and stop those also. An easier way is to press the double X's symbol. That will close every section related to a finished process, and might show you one that is still running, that you can stop. Continue pressing the double x and the stop button until all are gone, and you should be able to delete your jar, and build without issue.
Upvotes: 3