I am using maven 2.2.1, jdk 1.6.0_23 (64 bit) on a 64 bit windows 7 dell latitude (E6510). Although not reproducible, on a daily basis my build (large project, 67 artifactIds) will fail when running a clean because a directory cannot be deleted. I can change to that particular module and rerun the clean and it works. I can minimize the problem by running with the -fae (fail at end).
The failures are not because I am looking at files in the target.
None of the other developers in the office experience this problem. I am the only one running 64 bit windows 7.
I have also changed out my harddrive from a 5400rpm to a 7600rpm, but I am still getting the failure.
I searched around and did not find anything which said there is an inherent problem with large maven project builds and windows 7. The closest I have found is an old maven 1 bug (http://jira.codehaus.org/browse/MAVEN-1733)
My next step is to run linux on the same machine. I have setup my machine to dual boot to either windows 7 or ubuntu to see if I get the failure when building on ubuntu. Is there something else I could try?
There are two likely explanations; something in your code is being sloppy with file handles or you are encountering a 64-bit JVM issue, which due to Windows file locking is more visible than on other environments/VM’s.
There is a large cluster of bugs that can be tracked by linking to/from MSHARED-148, and it has consequences into a lot of plugins.
These problems can/will be fixed by upgrading all your plugins to the latest versions, as can be found here. It has been fixed in all core maven plugins (even some which don’t explicitly link to the above issue), I cannot give you the exact status for codehaus plugins. You may also consider switching to the latest maven 3.0.X.
A common trait to these issues is that they appear much more frequently on 64-bit JVM’s due to
the differences in JIT architecture (64 bit JVM’s basically still use “server” architectures). It gets worse in larger multimodule builds, since the JIT compiler usually kicks in further after a handful of invocations of the plugin code.