我在 Windows 7 上构建时遇到随机 Maven 构建失败，这是 Windows 问题吗？
我在 64 位 windows 7 dell latitude (E6510) 上使用 maven 2.2.1、jdk 1.6.0_23 (64 位)。尽管不可重现，但每天我的构建（大型项目，67 个artifactIds）在运行清理时都会失败，因为无法删除目录。我可以更改为该特定模块并重新运行 clean 并且它可以工作。我可以通过使用 -fae 运行（最后失败）来最小化问题。
失败并不是因为我正在查看目标中的文件。
办公室里的其他开发人员都没有遇到过这个问题。我是唯一运行 64 位 Windows 7 的人。
我也将硬盘从 5400rpm 更改为 7600rpm，但仍然出现故障。
我四处搜索，没有找到任何表明大型 Maven 项目构建和 Windows 7 存在固有问题的内容。我发现的最接近的是旧的 Maven 1 Bug (http://jira.codehaus.org/browse/MAVEN-第1733章 1733）
我的下一步是在同一台机器上运行Linux。我已将我的机器设置为双重启动到 Windows 7 或 ubuntu，以查看在 ubuntu 上构建时是否出现故障。我还有什么可以尝试的吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有两种可能的解释：您的代码中的某些内容与文件句柄有关，或者您遇到了 64 位 JVM 问题，由于 Windows 文件锁定，该问题比其他环境/VM 上更明显。
有一个大型错误集群，可以通过链接到/来自 进行跟踪MSHARED-148，它会对很多插件产生影响。
这些问题可以通过将所有插件升级到最新版本来解决，如此处< /a>.它已在所有核心 Maven 插件中得到修复（甚至一些没有明确链接到上述问题的插件），我无法为您提供 Codehaus 插件的确切状态。您也可以考虑切换到最新的maven 3.0.X。
这些问题的一个共同特征是，由于以下原因，它们在 64 位 JVM 上出现的频率更高
JIT架构的差异（64位JVM基本上仍然使用“服务器”架构）。在较大的多模块构建中，情况会变得更糟，因为 JIT 编译器通常会在多次调用插件代码后进一步启动。
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.
这可能与 Windows 有关，因为当前正在使用的文件可能无法删除。 Linux 和其他Unice 不存在这个问题。
话虽这么说，这可能是由于配置问题或某些第三方插件导致问题而表现出来的。
我将使用以下清单：
This might be related to Windows since files which are currently in use may not be deleted. Linux and other Unices do not have that problem.
That being said, this might manifest itself because of a configuration issue or some third-party plugin which causes problems.
I would use the following checklist: