PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3345 *** shadow/3345 Wed Aug 29 13:06:23 2001 --- shadow/3345.tmp.5992 Wed Aug 29 13:06:24 2001 *************** *** 0 **** --- 1,45 ---- + +============================================================================+ + | Modern compiler, run within Ant, holds onto JAR file locks on Windows | + +----------------------------------------------------------------------------+ + | Bug #: 3345 Product: Ant | + | Status: NEW Version: 1.4Beta2 | + | Resolution: Platform: PC | + | Severity: Normal OS/Version: Windows NT/2K | + | Priority: Other Component: Core tasks | + +----------------------------------------------------------------------------+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + I have heard it reported frequently that people running Ant from inside NetBeans + (which reuses the same VM, does not spawn) have troubles with file locks after + compiling with modern <javac> on Windows. Finally came up with a self-contained + test case which reproduces it. Unpack the (to-be-attached) ZIP into a fresh + directory and run the Ant script on Windows (I used Win2K). It should give an + error saying it failed to delete a JAR file. Try again (make sure it is using a + different directory this time, e.g. wait a minute) with a different + build.compiler - classic works fine, extjavac works fine, etc., it is only + modern that produces the problem. + + The problem seems to be that the modern compiler opens a JAR file present in the + classpath and does not clean up (release the file lock, i.e. ZipFile.close()). + On Unix and so on this does not matter (advisory locking). On Windows it + prevents any modifications to the file until the VM is exited. + + Mostly affects people using NetBeans or others tools which could run Ant + repeatedly in one VM; frequently heard as "clean target does not work until VM + restarted". But as demonstrated here it can be observed in standalone Ant as + well. I was unable to find any obvious problem by looking through 1.3 Javac + sources. + + ---- + + Originally reported against NetBeans as: + + http://www.netbeans.org/issues/show_bug.cgi?id=14843 + + Credits goes to [EMAIL PROTECTED] for working on a small test case to + reproduce with.
