Aas I was working with some ANT scripts today (well, yesterday by the time I finish the post) I stumbled upon a strange situation (or so I thought at first): my ANT task failed when trying to delete some JAR files. I checked the path to the file – it was correct. I checked if the file existed – it was there, waiting quietly. I checked its properties – it was read-only. I said bingo, changed the attribute and ran the task again. 2 seconds later, the same error. I checked whether other programs had the file opened. None.
Some minutes later, after searching for a bit on the net I verified the system CLASSPATH environment variable. And there were the two causes: I had the . added to the classpath. And so it seems that this is why JARS cannot be removed automatically by ANT.
Now, as a rule of thumb, it’s not very smart to have the . in your classpath variable (in my defence I added it for a test before leaving work the previous day and forgot to put it out), but if you run into files that will not die, check it out – it’s worth a look.
Cristi's thoughts 
1. Deletion issue
All the files from the PATH environment variable are ‘locked’ since the Windows Operating System keeps a reference to them.
And obviously no script (ANT, NullSoft) will not be able to delete them.
2. ‘.’ in CLASSPATH
Note: The CLASSPATH in Java is different from the PATH environment variable. I am sure that you can read more about this on Internet.
Since ANT is Java based is has no relevance how the build is started. But there is need to have the ‘.’ in the CLASSPATH because the ‘.’ can be easily obtained even in ANT from the ‘user.dir’ default system property from Java.
A very easy way to handle classpath issues in ANT is to use a setting in the build script like this:
You can have more than one path’s defined and use them how you think is appropriate. My suggestion is to have one for development and one for testing (eventually another for deployment).
If you need more details about this you know how to find me 🙂