Maven 或 Ivy 用于管理 Ant 的依赖关系？

Posted 2023-02-27

【中文标题】Maven 或 Ivy 用于管理 Ant 的依赖关系？

【英文标题】：Maven or Ivy for Managing Dependencies from Ant?

【发布时间】：2010-09-24 01:05:08

【问题描述】：

我想知道从 ant 管理项目依赖项的最佳方法。 Maven Ant 任务和 Ivy 的优缺点是什么？

【参考方案1】：

由于您想要做的是向现有 Ant 项目添加依赖管理，这正是 Ivy 的设计目的。依赖管理是 Maven 的重要组成部分，但远非全部。 Maven 更像是一个面向项目的工具，除了依赖关系之外，它还可以做其他几件事。如果您打算迁移到 Maven 并同时使用其他 Maven 功能，这将是值得考虑的，但如果您只是将其用于剥离 Ant，那就有点过分了。

您的依赖类型以及您对它们行为方式的期望也会产生影响。在 Maven 中拉取第三方依赖几乎是微不足道的，而 Ivy 擅长重建自己的依赖组件。在任何一种情况下，这些工具都不会提供像样的构建、版本控制和存储库策略，这些仍然取决于您并且需要正确配置。

【参考方案2】：

Ant + Ivy == 一个露营地，人们可以根据需要使用这些设施。 Maven == 一个度假村，您可以依靠其他人提供服务。

Maven 对于缺乏构建/集成经验的团队来说更容易，但是当团队需要偏离 Maven 标准时，他们会发现自己使用 groovy、gradle，而缺乏可靠的文档将变得令人沮丧。

Ant + Ivy 启动项目需要更长的时间，但如果团队有构建/集成经验，他们可以根据他们开发和发布代码的方式定制构建系统。

在工程...技术公司中，我总是推动露营地解决方案而不是度假村。

令人惊奇的是，Ant 和 Maven 都选择 XML 作为他们的语言来表达构建配方。 Java 社区一直停留在那个 XML 上……

【讨论】：

XMHell..如果有问题，你没有使用足够.. [暴力].. +1常春藤！

【参考方案3】：

我认为这篇博文完全涵盖了 OP 正在寻找的内容：

Why you should use the Maven Ant Tasks instead of Maven or Ivy

【参考方案4】：

Ivy+Ant 更加灵活。 Ivy 做依赖管理，周期，它做得非常好，比 Maven 更好。使用 Ant，您几乎可以组合任何您想要的构建系统。

Maven 试图控制一切——“生命周期”（编译、测试、打包等）、文件应该存在的位置等等。如果您不喜欢“Maven 方式”，请享受自定义插件等的乐趣。

Maven 是对无人问及的问题的答案。编写 Ant 脚本并不难，而且 Ivy 提供了比 Maven 更好的依赖管理。我对以前的一些 cmets 表示他们无法让 Ivy 工作感到困惑。 Ivy 比 Maven 更容易启动和运行。

Spring 框架在其构建过程中使用 Ivy。我认为这可以看作是对 Ivy 的信任投票。

【参考方案5】：

如果您的长期目标是迁移到使用 Maven 来管理整个构建过程（可能打算为新的未开发项目执行此操作），那么我衷心推荐使用 Maven pom.xml 文件来代表 Ant 管理依赖项build.xml 文件。最终结果是，您的新建项目和遗留项目都使用相同的机制来管理依赖项。事实证明，在管理 Ant build.xml 文件的依赖项方面，Maven 确实比 Ivy 做得更好。

在采用 Maven 作为我们的旗舰构建工具之前，我曾让开发人员尝试将 Ivy 与现有的 Ant build.xml 文件结合使用。这是最令人沮丧的经历，很快我们就拒绝了常春藤。我们继续采用 Maven。我们的新建项目开始使用现有的 Maven 方法等构建。

但是，我回到了 Ant 遗留项目并开始使用 Maven Ant 任务来定义类路径定义（偶尔还会从 pom.xml 中提取其他 Ant 属性定义）。事实证明，这是一次***的体验。现有的 Ant build.xml 文件只需稍作修改，即可使用 Maven ant 集成来定义 build.xml 文件中使用的任何类路径。项目所需的所有依赖项都在随附的 pom.xml 文件中定义，Maven 通过合并到 build.xml 文件中的 Ant 任务处理该文件。

Maven 作用域可用于微调类路径定义，以便建立一个适合编译、运行单元测试或打包等的定义。此外，几乎任何在 pom.xml 文件中定义的元素都可以在 build.xml 文件中作为 Ant 属性进行引用。

真的，对于 Maven 的 Ant 任务，Ivy 甚至没有存在的可行理由。

【参考方案6】：

将 Maven 与 ivy/ant 进行比较就像将智能手机与电报进行比较。

如果您想在构建基础架构中发挥真正持久的效果，最好使用 Maven，因为它可以预测和抽象每个软件项目或其他类似软件的项目面临的所有流程和任务。我参与了很多项目，如果你的项目变得更复杂、更多样化、更异构，你会更加称赞 Maven 项目配置的简单性。确实，与 ivy/ant 驱动的项目相比，它会变得复杂但并不复杂。

Maven 的主要优势是“约定优于配置”（http://en.wikipedia.org/wiki/Convention_over_configuration）一个非常重要的范例。简而言之，这意味着您不需要知道/配置明显/琐碎/常见的事情。尽管 Maven 及其所有插件附带了许多默认设置，但您始终可以选择配置项目以满足您的特殊需求。使用 Maven，一方面您可以非常轻松快速地设置项目；另一方面，您可以毫不费力地根据您的需要定制一个不断增长的项目。如果您了解 Maven 背后的关键概念，您将利用每个项目以及非典型软件开发项目的项目。

过去，我写了很多 ant 脚本，随着即将推出的 Maven，我开始讨厌 ant。一个缺点是你总是复制脚本并重复自己，开发不重复任务的 ant 任务不重复不重复的任务......而主要缺点是不断增长的 ant 脚本往往无法维护，尤其是如果十几个蚂蚁极客想互相拉皮条的话。

许多蚂蚁爱好者都无法完全控制琐碎的事情，例如复制工件和打印构建消息。但是因为 Maven 的关键概念是隐藏这些琐碎的事情，所以 Maven 限制定制需求的传说将永远存在。不过别担心，那是传说！所以你终于明白了我最初的陈述：不要为已经解决的琐碎事情烦恼。

也许 ivy/ant 是简单项目的选择，但对于复杂的成长项目，您需要简单和约定。否则你会被越来越多的维护问题压得喘不过气来。尤其是如果您在一个全球项目中有许多依赖项目、技术和异构产品部分，那么您就没有时间和金钱来开发和测试 ant 脚本或解决依赖问题。

另外一个建议是：Ant 提供了 Maven 的集成。这种集成通常用于在与 ant 一起成长的项目中测试和使用 maven。避免这种愚蠢的方法，因为它会产生更多问题。而是留在 ant 和它的痛苦中，或者完全迁移到 maven。

如果您对迁移成本有疑问，我建议您使用相反的方式通过 Maven-Ant-Plugin 集成不同的世界。使用这个标准插件，您可以毫不费力地运行每个 ant 脚本。当然，它在一段时间内是一个遗留解决方案，但它给了你尽可能多的时间来理解你的前任的大量扭曲的、未注释的 ant 脚本。

现在您将称赞 maven 的下一个优势：您需要的配置文档非常少，因为文档是您想要使用的每个 maven 插件的一部分。

所以我承认我是一个 Maven 对抗者。

【参考方案7】：

我知道 Ivy 的一个优点是它可以使用不同类型的存储库。 Maven 通常在它将使用的存储库格式方面非常严格。这就是我所知道的。

【参考方案8】：

我刚刚花了 2 天时间阅读 Ivy 文档，我不得不说，如果您有任何选择，请使用 MAVEN。据我所知，常春藤完全是垃圾。我只是浪费了 2 天时间试图将其整合到我的构建中，现在正在减少我的损失。为什么？

Ivy 在依赖管理方面是半途而废的尝试 Ivy 文档完全是个笑话 Ivy 例子和教程没用

我一引入“配置”（读作 maven 配置文件），Ivy 就开始疯狂下载各种我不需要的垃圾，然后失败了。 Ivy 的文档完全是个笑话。相比之下，Maven 文档读起来就像做梦一样。如果您想了解 Ivy 文档是多么难以理解和写得多么糟糕，请查看 configurations 的参考页面。这些是任何构建的重要组成部分，但在 Ivy 中，它们似乎是经过深思熟虑后设计的。

【讨论】：

您似乎在错误地使用 ivy 配置。尝试查看教程...ant.apache.org/ivy/history/latest-milestone/tutorial/conf.html

我无法让它工作！=它不起作用。顺便说一句，我从来没有使用过常春藤，但这篇文章可以用一些更具体的例子和更少的言辞来完成。