This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I am not sure if I selected the correct cateogry. Please redirect as appropriate. A little prerequisite to reproduce this bug is necessary and I am sorry for that. This is necessary mainly because I am facing a real problem with this and I just want to simulate the situation. - install the latest GlassFish build. This is only so that you can get access to few large jars on which a project might depend. This is really a quick step. - explode the attached jar. - open the project by doing File->Open Project ... - modify the GlassFish location so that now, this project uses the large jars from your installation. Scanning of classpaths starts, and it goes on for few minutes. Once that's done and mdrstorage is created, all the appserver jars that this project refers to, are LOCKED. That's it. You can't touch those jars anymore on Windows. Open the same Project in NB 4.1. No problem. Why is this a *huge* problem? GlassFish has an ant/maven based build that modifies the appserver jars during the build. This is a way to quickly update the jars and debug your issues. I use NetBeans to develop/debug. Once I modify the source, I go to command line and do the maven build of sources I modified. The build fails as long as the project is open in NetBeans. Once I close the project, everything is all right. Again, this does *not* happen with NB 4.1. This is a definite defect with scanning of classpaths for a project. I am pretty sure that it is a regression from 4.1. This poses a *huge* problem for me with my GlassFish build. As you know, GlassFish/NetBeans collaboration is critical and for that to happen, we have to get this fixed asap.
Created attachment 29402 [details] the jar fie with everything in it.
If it's really a problem with the scanning system, then not a project issue, but rather javacore. That is speculation at this point though. Generally these issues can be hard to track down since you need to find the code which opened a file lock (probably java.util.jar.JarFile in this case) and failed to release it. The only good way to do that (as far as I know) is to either guess in the dark; or run a memory profiler, which requires reproducibility. Do you have some kind of self-contained, reproducible test case that does not refer to Glassfish or external software? Certainly high priority if this happens regularly in different contexts, but we don't know that yet.
Thank you, for looking into it. Basically, I tried it with a standalone simple jar that has few classes as a library that I refer to from within my classes in project and I can not reproduce this. Then I tried to use a few jars that are reasonable in size (from few KB to few MB) and then I certainly can reproduce this a 100% of the times. Actually, I first hit this issue with successfully working GlassFish builds. I was happy that I created a project that contains sources from various CVS modules and then using these jars to resolve everything. I was happy that all the red ugly underlines had gone since all the classes were successfully resolved by the scanning system. This was with 4.1. I moved to 5.0 and immediately started seeing this problem. Ludo asked me to create a standalone case independent of GlassFish build and I did the same. The only thing I could not isolate was the number and sizes of jars that I refer to, from within my projects. The issue should not be hard to reproduce at all. Just download the GlassFish image from link I provided and then create a freeform project that refers to the jars from its lib directory. You can pick a handful of them. Start the IDE. Try to do a "move appserv-rt.jar foo.jar"; Windows disallows it since file is locked.
Just to be sure, that scanning is the evil, please try to run netbeans with "-J-Dnetbeans.javacore.noscan=true" and try the same scenario. Thanks.
kmhaswad?
I have the same problem: Netbeans locks my jars so I cannot delete them. As suggested, I tried switching off scanning, but it did not make any difference. In order to see which process actually owns the lock, I used Process Explorer by sysinternals.com (see attachment). It is definitely a Netbeans subprocess holding the lock. If I remove the lock manually I can delete the jars. The problem occurs even if cleaning is the first thing I do after starting the IDE. The project I used was a freeform project. I use: JDK 1.5.0_06 The error message I get from Ant: "Deleting directory C:\_work\workspace\web3CI\src\web\WEB-INF\lib C:\_work\workspace\web3CI\buildMWX.xml:331: Unable to delete file C:\_work\workspace\web3CI\src\web\WEB-INF\lib\commons-collections.jar" The attachment shows the process tree as displayed by Process Explorer and the handle the java process holds on the file I wanted to delete.
Created attachment 31671 [details] Process Explorer showing the process tree and the handle on a jar
My problem is a little different than that of denbo's. Though this bug is in incomplete state, I think there is something wrong. I will try it out on some other Windows box and revalidate my findings. Someone told me (Vince, Sreeram) that in my particular case, the NetBeans IDE holds locks to my GlassFish library jars if any of the GlassFish domains is registered in the IDE as a target server. But I am not sure that that's right. Anyway, I will confirm this soon. Thanks (denbo) for adding your comments to this bug.
Javacore module was replaced by Retouche infrastructure. This bug is not valid in trunk any more.
Reorganization of java component