当依赖关系过时时如何破坏 Maven 构建？答案

【问题标题】：How to break a maven build when dependencies are out of date?当依赖关系过时时如何破坏 Maven 构建？
【发布时间】：2011-05-23 13:10:09
【问题描述】：

我喜欢maven-versions-plugin，但有时我会忘记运行它一段时间。当某些重要的依赖关系过期时，有没有办法让 maven 构建失败（从而导致持续构建失败）？

【问题讨论】：

标签： maven-2 continuous-integration dependencies

【解决方案1】：

我认为您的处理方法不正确。如果您愿意，可以将 maven-versions-plugin 的输出邮寄给自己，但不要因为您无法控制的更改而导致构建失败。

更重要的是，您为什么要不必要地更新到最新版本？我已经看到由于升级而出现了许多棘手的问题，这些升级对以前的行为带来了轻微的变化。

【讨论】：

“重要依赖项”是指我公司其他团队开发的 jars。一旦有新版本可用，我应该升级。如果有问题，其他团队应该很快知道。
我不会每天都阅读一封电子邮件，没有任何区别。我想要一个只有在有新罐子时才会出现的警报。我不会失败的构建，我会失败的构建。没什么大不了的。
您考虑过使用版本范围吗？
版本范围会导致新版本出现时编译和测试失败。我想立即知道新版本何时发布，但仍需手动更新。这样我仍然可以检查任何修订，它会构建。

【解决方案2】：

这通常是一种不好的做法 - 自动更新版本。使用任何软件包的最新版本没有实际理由。如果您使用的库满足您的要求，出于安全/稳定性原因，您应该使用此版本。并且永远。

我认为maven-versions-plugin 本身就是一种反模式。

ps。如果您想对不同团队/程序员开发的模块进行集成测试，那就是“集成测试”。即使在这种情况下，我仍然认为即时版本更新是错误的方法。根项目不应进行此集成测试，相反，每个子模块（或 JAR，在您的情况下）必须负责自身与系统其余部分的集成测试。当子模块增加其版本时，它必须验证一切是否仍然正常，然后才必须向存储库发布新版本。当子模块进行验证时，它必须依赖于静态指定的版本号。

【讨论】：

查看其他答案的 cmets。
我确实静态指定了所有版本号。这就是为什么我需要设置第二个单独的构建，它会在我需要手动更新依赖项时提醒我，希望在同一天。
@Craig 对，但问题是 - 为什么需要更新版本？是什么原因？只是为了更新？为什么要为此操作花费时间/精力？如果项目有效，为什么要对其进行更改？这更像是 SDLC 的问题而不是 Maven 的问题 :) 抱歉，如果我的回答让您感到困惑
@Vincenzo 我开发库和框架，所以我想快速更新有两个原因。首先，如果我不升级，我公司中依赖我库的其他团队也无法升级。其次，作为一名库开发人员，我可以很好地向其他内部开发库的团队报告，并让他们知道在集成过程中是否有任何问题。
@Craig 你的解释是不正确的 SDLC 组织的好兆头。当下行链路（您的库的用户）需要来自上行链路（您的库）的某些特定新功能时，应该进行版本升级。为了健全性检查，它不应该发生（“我们仍然可以使用最新版本吗？”）。主要是因为这样的健全性检查没有人对问题负责。如果在健全性检查过程中检测到问题，我们不知道应该由谁来解决它。缺乏明确的责任是 SDLC 缺陷的明确指标。