Maven或Ivy用于管理来自Ant的依赖关系?

因为您想要做的是将依赖关系管理添加到现有的Ant项目中,这正是Ivy设计的目的。依赖关系管理是Maven的重要组成部分,但远不是全部。Maven更像是一个面向项目的工具,除了依赖性之外,它还做其他一些事情。如果您计划迁移到Maven并使用其他Maven特性,那么这是值得考虑的,但是如果您只想使用它来剥离Ant,那就有点过分了。

你的依赖类型和你对它们行为的期望也会有所不同。在Maven中,提取第三方依赖项几乎是微不足道的,而Ivy则擅长于重建自己的依赖组件。在这两种情况下,这些工具都无法提供良好的构建、版本控制和存储库 ,这些仍然取决于您,需要正确配置。

蚂蚁+常春藤==人们根据需要使用设施的露营地。
Maven==一个度假胜地,在这里你可以依靠其他人提供服务。

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

在工程方面。。。我一直在推动的技术公司是营地解决方案,而不是度假村。

尽管如此,Ant和Maven都选择XML作为表达构建方法的语言,这还是令人惊讶的。Java社区被困在XML上。。。

常春藤+蚂蚁更灵活。Ivy做依赖管理,period,它做得非常好,比Maven好。使用Ant,您几乎可以组装任何您想要的构建系统。

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

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

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

如果您的长期目标是迁移到使用Maven来管理整个构建过程(对于新的绿地项目可能打算这样做),那么我衷心推荐使用Maven pom.xml文件来代表Ant build.xml文件管理依赖关系。最终的结果是,您的绿地项目和遗留项目都使用相同的机制来管理依赖关系。事实证明,Maven在管理Ant build.xml文件的依赖项方面确实比Ivy做得更好。

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

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

实际上,对于Maven的Ant任务来说,常春藤甚至不存在任何可行的理由。

如果您想在构建基础设施中利用真正持久的效果,最好使用Maven,因为它可以预测和抽象每个软件项目或其他类似软件项目所面临的所有过程和任务。我参加过许多项目,如果您的项目变得更复杂、更多样化、更异构,您会更加赞赏Maven项目配置的简单性。事实上,与常春藤/蚂蚁驱动的项目相比,它将变得复杂,但并不复杂。

Maven的主要优点是“约定优于配置”(http://en.wikipedia.org/wiki/Convention_over_configuration)一个非常重要的范例。简而言之,这意味着您不需要知道/配置显而易见/琐碎/平凡的事情。尽管Maven及其所有插件都附带了许多默认设置,但您始终可以根据自己的特殊需要配置项目。有了Maven,一方面你可以轻松快速地建立一个项目;另一方面,您可以通过最少的努力定制一个不断增长的项目,以满足您的需求。如果您已经理解了Maven背后的关键概念,那么您将利用每个项目,以及不是典型软件开发项目的项目。

在过去,我写了很多ant脚本,随着即将到来的Maven,我开始讨厌ant。一个缺点是您总是复制脚本并重复自己,开发不重复任务的ant任务,不重复不重复的任务。。。主要的缺点是,不断增长的ant脚本往往无法维护,特别是如果十几个ant极客想相互推销ant脚本的话。

许多蚂蚁爱好者在复制工件和打印构建消息等琐碎的事情上受到全面控制。但由于Maven的关键概念是隐藏这些琐碎的东西,因此Maven限制定制需求的传奇将永远存在。但别担心,这是一个传奇!所以你们终于明白了我最初的说法:不要为已经解决的琐事烦恼。

也许ivy/ant是简单项目的一种选择,但对于复杂的成长项目,您需要简单性和约定。否则,您将面临越来越多的维护问题。特别是如果您在一个全局项目中有许多依赖的项目、技术和异构产品部件,那么您就没有时间和金钱来开发和测试ant脚本或解决依赖性问题。

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

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

所以我承认我是一个专业的对手。

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

• 常春藤的记录完全是个笑话
• 常春藤的例子和教程是无用的

configurations . 这些都是任何建筑的重要组成部分,但在常春藤中,它们似乎是经过深思熟虑后设计得很糟糕的。