2

我的代码中有一个测试，它创建一个目录，然后在其中创建一个文件。

但是，此测试失败，因为写入文件的测试部分无法找到创建的目录。唯一解决它的是将surefire插件设置为永远不会像这样分叉：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <forkMode>never</forkMode>
    </configuration>
</plugin>

我会将此修复解释为目录是在一个 JVM 进程中创建的，而文件是在另一个 JVM 进程/线程中创建的？

此测试失败与最近才开始失败的单台机器隔离。

我尝试过的几件事是：

  1. 系统上有许多 JDK 版本，所以除了在许多其他系统上工作的版本（ 1.6.0_19 ）之外，所有版本都被删除了。
  2. 尝试从管理员 cmd 提示符对该项目运行“mvn 测试”。
  3. 检查父目录的权限是否正常。
  4. 尝试从头开始检查整个项目并做同样的事情。
  5. 检查发生这种情况的目录是否已从 AntiVirus 的 On-Access-Scanner 中排除。

以上似乎都没有任何效果。唯一不同的是<forkMode>配置。我无法弄清楚为什么该测试在它周围绝对没有代码更改或它正在测试的功能中突然停止工作。

使用的 maven-surefire-plugin 版本是2.12.4。如果缺少“从不”配置，则更新到最新版本 (2.14.1) 不会修复测试。

<forkMode>已弃用，但仅从 2.14 版开始。

我对潜在的问题可能是什么很感兴趣。我希望最终的结论不会像 HDD 或硬件问题那么简单。

4

1 回答 1

0

tl;博士：固定！

为用户制造了另一台全新的机器。它工作了一个小时左右，然后，你瞧，完全相同的问题。

普遍的共识是它必须是流氓 Windows 更新。所以我们尝试了几件事，比如将机器恢复到以前的状态。手动卸载 Windows 更新等。没有任何效果。

然后机器的主人顿悟了。显然，他已经习惯了这个注册表黑客，这就是这个超级神秘错误的原因。我们取消了那个，瞧，mvn clean install 工作正常！

我仍然很好奇它为什么会影响 java 进程，所以这里有一个后续问题：为什么这个 autorun-cmd 注册表黑客会影响 java/maven 进程？ （完成一个 gihub 存储库以隔离有问题的代码。）

感谢所有有用的评论。

于 2013-04-27T08:17:05.163 回答