我想知道从ant管理项目依赖的最佳方法。Maven Ant任务与Ivy的优缺点是什么？
8个回答
41
由于您想要的是向现有的Ant项目添加依赖项管理，这正是Ivy的设计目的。依赖项管理是Maven的一个重要组成部分，但远非全部。Maven更多是一个面向项目的工具，除了依赖项之外还做了其他几件事情。如果您计划迁移到Maven并使用其他Maven功能，那么值得考虑；但是，如果您只是用它来启动Ant，则有些过头了。
您所需依赖项的类型以及您对它们行为的期望也会产生影响。在Maven中提取第三方依赖关系几乎是微不足道的，而Ivy则擅长重建您自己的依赖组件。无论哪种情况，这些工具都不会提供良好的构建、版本控制和存储库策略，这些仍然由您自己决定，并且需要正确配置才能达到预期效果。
- Chris
40
Ant + Ivy == 一个营地，人们根据需要使用设施。
Maven == 一个度假村，你要依赖别人提供的服务。
对于那些缺乏构建/集成经验的团队来说，Maven 更容易上手，但当团队需要偏离 Maven 标准时，他们将不得不求助于 groovy、gradle，并且文档缺失会让人感到沮丧。
Ant + Ivy 启动项目需要更长时间，但如果团队拥有构建/集成经验，则可以根据自己的开发和发布代码方式定制构建系统。
在工程领域，我总是倾向于采用营地解决方案而非度假村。
令人惊奇的是，Ant 和 Maven 都选择 XML 作为表达构建配方的语言。Java 社区一直坚持使用 XML...
- kramer
1
5如果出现问题，那就不够使用... [暴力]... 为常春藤加一分！ - JavaRocky
8
Ivy+Ant非常灵活。Ivy专注于依赖管理，并且做得比Maven更好。而使用Ant，您几乎可以组合任何构建系统。
Maven试图控制一切——“生命周期”（编译、测试、打包等）、文件的存放位置等等。如果您不喜欢“Maven方式”，那么自定义插件等就会变得很困难。
Maven是一个没有人提出的问题的答案。编写Ant脚本并不难，而Ivy为您提供了比Maven更好的依赖管理。我对一些之前的评论感到困惑，他们声称无法让Ivy工作。实际上，相比Maven来说，Ivy要简单得多。
Spring Framework在其构建过程中使用Ivy。我认为这可以视为对Ivy的高度信任。
Maven试图控制一切——“生命周期”（编译、测试、打包等）、文件的存放位置等等。如果您不喜欢“Maven方式”，那么自定义插件等就会变得很困难。
Maven是一个没有人提出的问题的答案。编写Ant脚本并不难，而Ivy为您提供了比Maven更好的依赖管理。我对一些之前的评论感到困惑，他们声称无法让Ivy工作。实际上，相比Maven来说，Ivy要简单得多。
Spring Framework在其构建过程中使用Ivy。我认为这可以视为对Ivy的高度信任。
- BCK
7
如果您的长期目标是迁移到使用Maven来管理整个构建过程（这可能是新的绿色项目的意图），那么我强烈推荐使用Maven pom.xml文件代表Ant build.xml文件来管理依赖项。最终结果是，您的绿色项目和旧项目都使用相同的机制来管理依赖项。事实证明，Maven比Ivy更适合管理Ant build.xml文件的依赖关系。
在采用Maven作为我们的主要构建工具之前，我曾经让开发人员尝试使用Ivy与现有的Ant build.xml文件结合使用。这是一个非常令人沮丧的经历，很快就让我们拒绝了Ivy。我们决定采用Maven。我们的绿色项目开始使用标准的Maven方法进行构建等。
然而，我回到了Ant旧项目，并开始使用Maven Ant任务来定义类路径定义（以及偶尔从pom.xml中引入的其他Ant属性定义）。这证明是一个非常出色的体验。现有的Ant build.xml文件只需要稍微修改一下，就可以使用Maven ant集成来定义在build.xml文件中使用的任何类路径。项目所需的所有依赖项都在附带的pom.xml文件中定义，该文件通过嵌入到build.xml文件中的Ant任务由Maven处理。
Maven范围可以用于微调类路径定义，从而可以建立适合编译、运行单元测试或打包等的类路径。此外，几乎可以将pom.xml文件中定义的任何元素作为Ant属性在build.xml文件中引用。
实际上，对于Maven的Ant任务，甚至没有理由让Ivy存在。
在采用Maven作为我们的主要构建工具之前，我曾经让开发人员尝试使用Ivy与现有的Ant build.xml文件结合使用。这是一个非常令人沮丧的经历，很快就让我们拒绝了Ivy。我们决定采用Maven。我们的绿色项目开始使用标准的Maven方法进行构建等。
然而，我回到了Ant旧项目，并开始使用Maven Ant任务来定义类路径定义（以及偶尔从pom.xml中引入的其他Ant属性定义）。这证明是一个非常出色的体验。现有的Ant build.xml文件只需要稍微修改一下，就可以使用Maven ant集成来定义在build.xml文件中使用的任何类路径。项目所需的所有依赖项都在附带的pom.xml文件中定义，该文件通过嵌入到build.xml文件中的Ant任务由Maven处理。
Maven范围可以用于微调类路径定义，从而可以建立适合编译、运行单元测试或打包等的类路径。此外，几乎可以将pom.xml文件中定义的任何元素作为Ant属性在build.xml文件中引用。
实际上，对于Maven的Ant任务，甚至没有理由让Ivy存在。
- RogerV
5
与ivy / ant相比，将Maven与电报机进行比较。
如果您想在构建基础架构中获得真正持久的效果，最好使用Maven，因为它预测并抽象出每个软件项目或其他类似软件项目面临的所有过程和任务。我参加了许多项目，如果您的项目变得更加复杂、多样化和异构化，您将更加赞赏Maven项目配置的简单性。实际上，与ivy / ant驱动的项目相比，它会变得复杂但不复杂。
Maven的主要优点是“约定优于配置”（http://en.wikipedia.org/wiki/Convention_over_configuration），这是一个非常重要的范例。简而言之，这意味着您不需要知道/配置显而易见/平凡/常见的事情。虽然Maven及其所有插件都带有许多默认设置，但您始终可以选择根据特殊需求配置您的项目。一方面，您可以很容易地快速设置项目；另一方面，您可以以最小的努力自定义增长的项目以满足您的需求。如果您已经理解了Maven背后的关键概念，您将利用每个项目，包括那些不典型的软件开发项目。
过去，我编写了许多ant脚本，随着即将到来的Maven，我开始讨厌ant。一个缺点是您始终会复制脚本并重复自己，开发ant任务而不是重复任务而不是重复任务......而且主要缺点是增长的ant脚本往往变得难以维护，特别是如果十几个ant极客想要升级彼此的ant脚本。
许多ant爱好者遭受控制诸如复制工件和打印构建消息之类的平凡事物的整体控制。但是，因为Maven的关键概念是隐藏这些平凡事物，所以传说将永远保持Maven限制自定义需求。但是不用担心，那只是一个传说！因此，您最终理解了我的初始声明：不要烦恼已经解决的琐碎问题。
也许ivy / ant对于简单项目是一种选择，但对于复杂的增长项目，您需要简单性和约定。否则，您将被越来越多的维护问题所压倒。特别是如果您有许多依赖项目、技术和全局项目中的异构产品部分，您就没有时间和金钱来开发和测试ant脚本或解决依赖性问题。
还应提到另一个建议：Ant提供了Maven的集成。通常使用此集成在使用ant生成的项目中测试和使用maven。避免这种愚蠢的方法，因为它会产生更多问题。相反，要么坚持使用ant及其痛苦，要么完全迁移到maven。
如果您对迁移成本有疑虑，我建议您使用Maven-Ant-Plugin的相反集成方式。使用此标准插件，您可以轻松运行每个ant脚本。当然，它是一个遗留解决方案一段时间，但它给您足够的时间来理解前任的巨大、扭曲且未注释的ant脚本。
现在，您将赞扬maven的下一个优点：您需要非常少的配置文档，因为
如果您想在构建基础架构中获得真正持久的效果，最好使用Maven，因为它预测并抽象出每个软件项目或其他类似软件项目面临的所有过程和任务。我参加了许多项目，如果您的项目变得更加复杂、多样化和异构化，您将更加赞赏Maven项目配置的简单性。实际上，与ivy / ant驱动的项目相比，它会变得复杂但不复杂。
Maven的主要优点是“约定优于配置”（http://en.wikipedia.org/wiki/Convention_over_configuration），这是一个非常重要的范例。简而言之，这意味着您不需要知道/配置显而易见/平凡/常见的事情。虽然Maven及其所有插件都带有许多默认设置，但您始终可以选择根据特殊需求配置您的项目。一方面，您可以很容易地快速设置项目；另一方面，您可以以最小的努力自定义增长的项目以满足您的需求。如果您已经理解了Maven背后的关键概念，您将利用每个项目，包括那些不典型的软件开发项目。
过去，我编写了许多ant脚本，随着即将到来的Maven，我开始讨厌ant。一个缺点是您始终会复制脚本并重复自己，开发ant任务而不是重复任务而不是重复任务......而且主要缺点是增长的ant脚本往往变得难以维护，特别是如果十几个ant极客想要升级彼此的ant脚本。
许多ant爱好者遭受控制诸如复制工件和打印构建消息之类的平凡事物的整体控制。但是，因为Maven的关键概念是隐藏这些平凡事物，所以传说将永远保持Maven限制自定义需求。但是不用担心，那只是一个传说！因此，您最终理解了我的初始声明：不要烦恼已经解决的琐碎问题。
也许ivy / ant对于简单项目是一种选择，但对于复杂的增长项目，您需要简单性和约定。否则，您将被越来越多的维护问题所压倒。特别是如果您有许多依赖项目、技术和全局项目中的异构产品部分，您就没有时间和金钱来开发和测试ant脚本或解决依赖性问题。
还应提到另一个建议：Ant提供了Maven的集成。通常使用此集成在使用ant生成的项目中测试和使用maven。避免这种愚蠢的方法，因为它会产生更多问题。相反，要么坚持使用ant及其痛苦，要么完全迁移到maven。
如果您对迁移成本有疑虑，我建议您使用Maven-Ant-Plugin的相反集成方式。使用此标准插件，您可以轻松运行每个ant脚本。当然，它是一个遗留解决方案一段时间，但它给您足够的时间来理解前任的巨大、扭曲且未注释的ant脚本。
现在，您将赞扬maven的下一个优点：您需要非常少的配置文档，因为
我承认我曾经对Maven持有反感态度。
- shylynx
2
我知道Ivy的一个优势是它可以使用不同类型的仓库。相比之下，Maven在使用仓库时通常非常严格。这就是我所知道的全部。
- David M. Karr
1
我刚刚花了两天时间阅读Ivy文档，不得不说，如果你有任何选择的话，请使用MAVEN。据我所知，Ivy完全是垃圾。我刚刚浪费了两天时间尝试将其纳入我的构建中，现在我正在削减损失。为什么？
- Ivy是对依赖管理的不负责任的尝试
- Ivy文档是一个彻头彻尾的笑话
- Ivy的示例和教程都是无用的
一旦我引入了“配置”（可以理解为maven配置文件），Ivy就开始疯狂下载我不需要的所有东西，然后失败了。与Maven相比，Ivy的文档简直是个笑话。如果你想看看Ivy文档有多难懂和糟糕，请看看configurations的参考页面。这些是任何构建的重要组成部分，但在Ivy中，它们似乎是一个设计不良的事后想法。
- Alex Worden
2
看起来你可能在错误地使用ivy配置。尝试查看教程...http://ant.apache.org/ivy/history/latest-milestone/tutorial/conf.html - Clintm
4我无法让它工作并不意味着它不能工作。顺便说一下，我从未使用过Ivy，但这篇文章可以提供更多具体的例子，少一些修辞。 - leonigmig
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接