CODEWITHSUNDEEP
antjarjavacfilehandle
karoberts
karoberts

Reputation: 9938

ant error Unable to rename old file to temporary file

I'm using ant 1.8.0 and java 1.6.0.17 and I'm running into a strange problem.

In my build.xml, I have a simple task that compiles the code

<javac destdir="${dir.build.classes}" debug="on">
    <classpath refid="classpath"/>
    <src path="${dir.src.java}"/>
</javac>

In the "classpath" is a jar, call it library.jar

In a later task, I need to add a few classes to library.jar, which I do like this

<jar destfile="library.jar" update="true" duplicate="fail">
    <fileset dir="${dir.build.classes}">
        <include name="some/class/files"/>
    </fileset>
</jar>

This will fail with the error Unable to rename old file (library.jar) to temporary file

I stuck in a call to handle.exe before and after the javac call, and I can confirm that the java process running ant grabs a file handle to library.jar during the javac call, and it doesn't give it up. This causes my later attempt to update the jar to fail.

Why would ant keep a handle to the jar in a classpath open even after the javac task is complete?

Upvotes: 7

Views: 6921

Answers (5)

Sriragavan Natesan
Sriragavan Natesan

Reputation: 11

I tried latest version of ANT(1.10.7) and its works for me.

This issue has been solved in 1.9.7

WHATSNEW in ant

FileUtils.java

Upvotes: 1

Faisal Feroz
Faisal Feroz

Reputation: 12785

There is a bug filed for the exact same issue here.

They are saying that this is fixed in Ant version 1.8

Upvotes: 1

user419040
user419040

Reputation: 1

It seems related to classpath configuration and The first operation on the jar file keeps it opened. I've resolved this issue by removing "." from my classpath env variable.

Upvotes: -1

karoberts
karoberts

Reputation: 9938

So I found the answer, after some experimentation. By adding fork="true" to my javac task, the file handle is closed at the end of the task. This allows my jar modification to succeed later in the build.

It's unfortunate though, because I have to remember to add this to every upstream javac task.

Upvotes: 5

Mark O&#39;Connor
Mark O&#39;Connor

Reputation: 77951

This is a windows locking issue. Any process/thread reading the file will prevent it from being renamed, which is what the zip task is doing, when updating an existing jar file.

I'm guessing that the file handle is being kept open because your using a classpath reference. Maybe the file handles might be closed if you were to explicitly set the javac task's classpath?

Upvotes: 3

Related Questions