6
votes

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..
5
Windows? If any file is open within the directory windows will refuse to delete. OS level error.Mark O'Connor
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.ken
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/…Mark O'Connor
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.mrswadge

5 Answers

3
votes

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:

enter image description here

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:

enter image description here

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:

enter image description here

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.

0
votes

Execute below from command line

c:\path_to_eclipse\eclipse.exe -clean

0
votes

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.

0
votes

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.

0
votes

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.