I'm using Maven 3 with Netbeans 6.9 to build and deploy a web application. I've got GlassFish 3.0.1 installed as the application server. If GlassFish is running and I've already got the web application deployed then executing the clean command will fail because it cannot delete jars that are opened by GlassFish. Undeploying the web application doesn't fix the problem. However, shutting down GlassFish does. Shutting down GlassFish to run a clean is a pain though.
I've read about Windows having strict rules about file locking with open files so I assume that is what is going on. I can use the clean command sparingly and just run builds, but just wondering if anyone else is experiencing this and if there is a better way?
If I'm running a vanilla web application without any packaged jars this isn't a problem. However, if I add libraries like Hibernate, PrimeFaces, slf4j, etc I see this issue. I am thinking that adding these dependencies into the lib/ext directory of GlassFish and marking them as provided in the POM would also fix this, but then the war is less portable because it expects the environemnt to provide all dependencies and makes using a SNAPSHOT much more burdensome.
You are correct. Windows employs a rather pessimistic locking scheme and uses the the filename/path as the key. So in order to delete the file, you have to remove all open references to it, even if they are read-only. This is why Windows has "reboot fever". A lot of critical system files are locked from the moment that the GUI starts until shutdown. Thus, the only way those files could be replaced is in the "blue screen of boot" timespan before the GUI starts back up. The files are actually queued up for replacement and if the replacement queue is non-empty, the new versions are copied into place at startup time.
Sources may include data from the Fakebook Research Foundation with support from Gargle University