maven-2 - 针对 Maven 的案子？

Question

我一次又一次地阅读和听到人们对 Maven 及其复杂性感到沮丧。而且使用 Ant 构建代码要容易得多。

但是，为了:

1. 编译代码
2. 运行测试
3. 打包可部署单元

这就是 Maven 所需要的:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>type something here</groupId>
  <artifactId>type something here</artifactId>
  <version>type something here</version>
</project>

相应的最小 Ant 构建文件是什么？

Answer 1

As Aaron says ，Maven 的问题不在于它如何工作，而在于它如何失败。

在 Ant 中，依赖管理是一个必须手动解决的问题(暂时忽略 Ivy，因为它本质上是固定在 Ant 上的 Maven 方法)。如果您有很多依赖项，这可能会很耗时，但这是一次性成本。一旦您组织好依赖项并将其 checkin 版本控制存储库，它就可以正常工作了。至少在您必须更改依赖项之前，希望这种情况很少发生(但在某些情况下并非如此)。

Maven 通过使依赖关系动态化来“解决”依赖关系问题，因此避免了大量的前期成本，并使更改依赖关系变得更容易。这种灵 active 的代价是复杂性。 Maven 将您的构建转变为分布式系统，这样做违反了许多 8 Fallacies of Distributed Computing 。其中一些问题更多的是理论上的问题而不是实践上的问题。例如，我不知道任何 Maven 存储库被破坏的情况，但这并不意味着您不必意识到安全隐患。远程存储库的其他问题(例如可靠性、带宽和延迟)是 Maven dissatisfaction 的更常见原因。 .

Maven 将在本地缓存依赖项，这样一旦您检索了项目所需的所有内容，就应该避免重复访问存储库。但随着时间的推移，随着项目开发人员数量的增长，您将多次需要重新检索依赖项。使用默认的 Maven 设置，您可以外包依赖管理。依赖项会在您需要时立即可用，还是服务器会停机？ 6 个月后仍可从远程存储库获取它吗？也许吧，但这不在你的控制范围内。

因此 Maven 拥护者会告诉您，您可以而且应该运行自己的 Maven 存储库，以避免分布式依赖项引起的许多问题。好的，但现在我们不能再假装 Maven 很简单了。 Maintaining your own Maven infrastructure can become quite involved .

过去人们对 Maven 感到愤怒的另一个原因是它的插件系统。 Maven 能够 self 更新，但通常这只会导致损坏。我相信这种行为在最新版本中已得到抑制。

Maven 可能仍然是某些环境的最佳解决方案，例如并行开发多个项目且它们之间存在一定耦合的团队，但它远非没有痛苦。

Ant 也不是没有痛苦的，但痛苦往往是你自己造成的，而不是你无法控制的。您需要引入更高级别的抽象来保持事物的可管理性。 Ant Macros在这方面是一个有用的工具。与some discipline and sensible conventions (也许像 Maven 所鼓励的那样？)您可以在大型项目中有效地使用 Ant。 Ant 构建文件与任何其他程序一样(嗯，除了冗长的 XML 语法)，它需要随着情况的变化而进行维护和重构，而不是仅仅修改它直到它看起来可以工作。 Ant 的优势在于它很健壮，通常会产生可重复的构建，并且有很好的文档记录。