36

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

4

8 回答 8

41

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

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

于 2008-11-25T21:11:42.373 回答
40

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

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

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

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

令人惊奇的是,Ant 和 Maven 都选择 XML 作为他们的语言来表达构建配方。Java 社区被困在那个 XML 上......

于 2009-05-07T02:51:50.447 回答
8

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

为什么你应该使用 Maven Ant Tasks 而不是 Maven 或 Ivy

于 2010-01-18T10:02:15.140 回答
8

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

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

Maven 是对无人问及的问题的答案。编写 Ant 脚本并不难,而且 Ivy 提供了比 Maven 更好的依赖管理。我对之前的一些评论感到困惑,他们说他们无法让 Ivy 工作。Ivy 比 Maven 启动和运行要简单得多。

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

于 2010-05-03T21:46:28.463 回答
7

如果您的长期目标是迁移到使用 Maven 来管理整个构建过程(可能打算为新的未开发项目执行此操作),那么我衷心推荐使用 Maven pom.xml 文件来代表 Ant build.xml 管理依赖项文件。最终结果是,您的新建项目和遗留项目都使用相同的机制来管理依赖项。事实证明,Maven 在管理 Ant build.xml 文件的依赖项方面确实比 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 甚至没有存在的可行理由。

于 2009-03-01T01:50:09.670 回答
5

将 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。避免这种愚蠢的方法,因为它会产生更多问题。而是留在蚂蚁和它的痛苦中,或者完全迁移到 Maven。

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

现在您将称赞 maven 的下一个优势:您需要的配置文档非常少,因为文档是您要使用的每个 maven-plugin 的一部分。

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

于 2012-01-26T17:59:25.797 回答
2

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

于 2008-11-25T21:02:49.193 回答
1

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

  • 常春藤是依赖管理的半途而废的尝试
  • 常春藤文档完全是个笑话
  • ivy例子和教程没用

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

于 2010-04-09T21:13:13.990 回答