eclipse ant build failed Unable to delete file lib\build

Question

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..

Former

Windows? If any file is open within the directory windows will refuse to delete. OS level error. – Parrot

It's not an error. it's a message, the file is locked. Eclipse-ant locks the file and will not release the lock unless restart of eclipse. I think it's a bug or "error" in eclipse ant plug-in, and it seems to be associated with the ivy dependency manager, because I've never seen this prior to ivy integration. – Former

More likely to be an OS issue, certainly that has been my experience. Any chance you're using locking strategy in your ivy settings file? Rarely needed and unlikely to be root case: ant.apache.org/ivy/history/latest-milestone/settings/… – Parrot

In my experience of Kepler, it locks jars that are mentioned on the classpath of projects. You don't need to actually run any process for the lock to materialize. I often have to stop Eclipse and run the ant task at the command window. I don't know if it would be easy to kill the handles to the problem jar files using SysInternals handle.exe, but I should think that would require elevated user rights, which might well be a problem. – Delenadeleon

Answer 1

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.

Housekeeping

That good info and well documented, but the ant process task is completed. The double XX doesn't work either. If the ant build fails for other reasons, the jar files are locked still too. Thus I think it's eclipse ant module that isn't handling exceptions well and bug in side of ant plugin. The ant-eclipse bug tracker shows something like this in ancient times circa 2004... bugs.eclipse.org/bugs/show_bug.cgi?id=64713 so is it similar problem pattern, it looks like it baseline problem with how the taskdef is referenced. The workaround might be changing the ant script (ugh.) – Former

Common sense: This occurs when a process is using said file. Thanks!! – Aguayo

Answer 2

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:

1. Open menu Window > Preferences > Ant > Editor > Content Assist
2. Disable the option Provide proposals for user defined tasks
3. Restart Eclipse

Megan

Thank you! The only answer that worked for me, restarting Eclipse isn't optional in this case, as it doesn't let go the file handles until that. – Extramural

Answer 3

Execute below from command line

c:\path_to_eclipse\eclipse.exe -clean

Lubbi

Answer 4

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.

Hawker

Answer 5

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.

Presidio

Answer 6

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.

Cawley