我想知道从ant管理项目依赖项的最佳方法。 Maven Ant任务和Ivy的优缺点是什么？
答案 0 :(得分：41)
因为你想要做的是将依赖管理添加到现有的Ant项目中，这正是Ivy设计的目的。依赖管理是Maven的重要组成部分，但远非所有。 Maven更像是一个面向项目的工具，除了依赖项之外还可以执行其他几项工作。如果您计划迁移到Maven并使用其他Maven功能，那将是值得考虑的，但如果你所有人都使用它，那就有点多了就是分拆Ant。
您的依赖类型以及您对其行为方式的期望也会产生影响。在Maven中拉取第三方依赖关系几乎是微不足道的，而Ivy在重建自己的依赖组件方面表现出色。在任何一种情况下，这些工具都不会提供合适的构建，版本控制和存储库策略，这些仍然取决于您并且需要正确配置。
答案 1 :(得分：40)
Ant + Ivy ==露营地，人们根据需要使用这些设施 Maven ==一个度假胜地，您依靠其他人提供服务。
Maven对于缺乏构建/集成体验的团队来说更容易，但是当团队需要与Maven标准不同时，他们会发现自己正在接受groovy，gradle，缺乏可靠的文档会变得令人沮丧。
Ant + Ivy将需要更长的时间来启动项目，但如果团队具有构建/集成经验，他们可以围绕他们开发和发布代码的方式定制构建系统。
在工程技术公司中，我总是推动营地解决方案而不是度假村。
令人惊讶的是，Ant和Maven都选择XML作为表达构建配方的语言。 Java社区坚持使用XML ......
答案 2 :(得分：8)
Ivy + Ant远远更灵活。 Ivy做依赖管理，期间，它做得非常好，比Maven好。使用Ant，您几乎可以将任何构建系统组合在一起。
Maven试图控制一切 - “生命周期”（编译，测试，包等），文件应该存在，等等。如果你不喜欢“Maven方式”，可以自定义插件等。
Maven是一个没有人问过的问题的答案。编写Ant脚本并不难，Ivy为您提供比Maven更好的依赖管理。我对以前的一些评论感到困惑，说他们无法让常春藤工作。启动和运行Ivy比Maven简单得多。
Spring Framework在其构建过程中使用Ivy。我认为这可以被视为对常春藤的信任投票。
答案 3 :(得分：7)
如果您的长期目标是迁移到使用Maven来管理整个构建过程（可能打算为新的绿地项目执行），那么我衷心建议使用Maven pom.xml文件代表Ant管理依赖项build.xml文件。最终结果是，您的绿地项目和遗留项目都使用相同的机制来管理依赖项。事实证明，Maven在管理Ant build.xml文件的依赖关系方面确实比常春藤更好。
在采用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存在。
答案 4 :(得分：7)
我认为这篇博文完全涵盖OP正在寻找的内容：
Why you should use the Maven Ant Tasks instead of Maven or Ivy
答案 5 :(得分：5)
将Maven与常春藤/蚂蚁进行比较是为了将智能手机与电报进行比较。
如果您想在构建基础架构中利用真正的持久效果，最好使用Maven，因为它可以预测和抽象每个软件项目或其他类似软件项目所面临的所有流程和任务。我参与了许多项目，如果您的项目变得更复杂，更多样化，更多样化，您将更加赞赏Maven项目配置的简单性。实际上，与常春藤/蚂蚁驱动的项目相比，它将变得复杂但并不复杂。
Maven的主要优点是“约定优于配置”（http://en.wikipedia.org/wiki/Convention_over_configuration）是一个非常重要的范例。简而言之，这意味着您不需要知道/配置明显/琐碎/普通的事物。虽然Maven及其所有插件都附带许多默认设置，但您始终可以选择根据您的特殊需求配置项目。使用Maven，一方面您可以非常轻松快速地设置项目;另一方面，您可以轻松定制不断增长的项目，以满足您的需求。如果您已经理解了Maven背后的关键概念，那么您将利用每个项目以及非典型软件开发项目的项目。
在过去，我写了很多蚂蚁脚本，随着即将到来的Maven，我开始讨厌蚂蚁。一个缺点是你总是复制脚本并重复自己，开发不重复任务的ant任务，这些任务不会重复不重复的任务......而主要的缺点是不断增长的ant脚本往往难以维护，尤其是如果十几个蚂蚁怪人想要彼此掠夺蚂蚁脚本。
许多蚂蚁爱好者都无法全面控制诸如复制文物和打印构建消息之类的琐碎事情。但是因为Maven的关键概念是隐藏这些琐碎的事物，所以传说将永远保持Maven限制定制需求。但不要担心，这是一个传奇！所以你终于理解了我最初的陈述：不要为已经解决的琐碎事情烦恼。
也许ivy / ant是简单项目的选项，但对于复杂的增长项目，您需要简单和惯例。否则你将面临越来越多的维护问题。特别是如果您在全球项目中有许多依赖项目，技术和异构产品部件，那么您就没有时间和金钱来开发和测试Ant脚本或解决依赖性问题。
应该提到另一个建议：Ant提供Maven的集成。这种集成通常用于在使用ant成长的项目中测试和使用maven。避免这种愚蠢的方法，因为它会产生更多问题。而是留在蚂蚁及其痛苦或完全迁移到maven。
如果您对迁移成本存在疑问，我建议您使用Maven-Ant-Plugin集成不同世界的相反方式。使用此标准插件，您可以毫不费力地运行每个ant脚本。当然它确实是一段时间的遗留解决方案，但是它为您提供了所需的时间来理解前一代巨大的歪曲的未注释的蚂蚁脚本。
现在，您将赞扬maven的下一个优势：您需要的配置文档非常少，因为文档是您要使用的每个maven-plugin的一部分。
所以我承认我是一名Maven-Antagonist。
答案 6 :(得分：2)
我知道Ivy的一个优点是它可以使用不同类型的存储库。 Maven通常在它将使用的存储库格式中非常严格。这就是我所知道的。
答案 7 :(得分：1)
我花了两天时间阅读常春藤文档，我不得不说，如果您有任何选择，请使用MAVEN。据我所知，常春藤是完整而彻底的垃圾。我只是浪费了2天试图将它融入我的构建中并且现在正在削减我的损失。为什么呢？
当我介绍'配置'（读作maven配置文件）时，Ivy开始下载各种垃圾，我不需要然后失败。常春藤的文档是一个彻头彻尾的笑话。相比之下，Maven文档就像一个梦想。如果您想了解Ivy文档的难以理解和写得不好的示例，请查看configurations的参考页面。这些是任何构建的重要组成部分，但在常春藤中，它们似乎是经过深思熟虑的设计。