I was wondering about the best way to manage projects dependencies from ant. What are the pros and cons of the Maven Ant task and of Ivy?
我想知道从ant管理项目依赖项的最佳方法。 Maven Ant任务和Ivy的优点和缺点是什么?
8 个解决方案
#1
41
Since what you're wanting to do is add dependency management to an existing Ant project, that's precisely what Ivy's designed to do. Dependency management is a big part of Maven, but far from all of it. Maven is more of a project-oriented tool that does several other things in addition to dependencies. It would be worth considering if you were planning to migrate to Maven and use additional Maven features as well, but it's a bit much if all you'd use it for is to spin off Ant.
因为你想要做的是将依赖管理添加到现有的Ant项目中,这正是Ivy设计的目的。依赖管理是Maven的重要组成部分,但远非所有这些。 Maven更像是一个面向项目的工具,除了依赖之外还可以执行其他几项工作。如果您计划迁移到Maven并使用其他Maven功能,那将是值得考虑的,但是如果你所有人都使用它来分离Ant就有点多了。
Your type of dependencies and your expectations for how they behave will also make a difference. Pulling third-party dependencies is almost trivial in Maven, while Ivy excels in rebuilding your own dependent components. In either case, the tools won't provide decent build, versioning, and repository policies, those are still up to you and needed to get the configuration right.
您的依赖类型以及您对其行为方式的期望也会产生影响。在Maven中拉取第三方依赖关系几乎是微不足道的,而Ivy在重建自己的依赖组件方面表现出色。在任何一种情况下,这些工具都不会提供合适的构建,版本控制和存储库策略,这些仍然取决于您并且需要正确配置。
#2
40
Ant + Ivy == A campground, where people use the facilities as needed.
Maven == A resort, where you rely on someone else to provide services.
Ant + Ivy ==露营地,人们根据需要使用这些设施。 Maven ==一个度假胜地,您依靠别人提供服务。
Maven is easier for a team lacking build/integration experience, but when the team needs to diverge from Maven standards they will find themselves reaching for groovy, gradle, and the lack of solid documentation will become frustrating.
Maven对于缺乏构建/集成体验的团队来说更容易,但是当团队需要与Maven标准不同时,他们会发现自己正在接受groovy,gradle,缺乏可靠的文档会变得令人沮丧。
Ant + Ivy will take longer to startup a project, but if the team has build/integration experience they can tailor the build system around they way they develop and release code.
Ant + Ivy需要更长的时间来启动项目,但如果团队具有构建/集成经验,他们可以围绕他们开发和发布代码的方式定制构建系统。
In engineering... technology companies I always push for the campsite solution versus the resort.
在工程......技术公司,我总是推动营地解决方案而不是度假村。
It is amazing though that both Ant and Maven choose XML as their langauge to express build recipes with. The Java community is stuck on that XML...
令人惊讶的是,Ant和Maven都选择XML作为表达构建配方的语言。 Java社区坚持使用XML ...
#3
8
Ivy+Ant is far, far more flexible. Ivy does dependency management, period, and it does that extremely well, better than Maven. And with Ant you can pretty much put together any build system that you want.
常春藤+蚂蚁远远更灵活。 Ivy做了依赖管理,期间,它做得非常好,比Maven好。使用Ant,您可以将任何您想要的构建系统组合在一起。
Maven tries to control everything - the "lifecycle" (compile, test, package, etc.), where files should live, and so on. Have fun customizing plugins and the like if you don't like the "Maven way".
Maven试图控制一切 - “生命周期”(编译,测试,包等),文件应该存在的地方,等等。如果您不喜欢“Maven方式”,可以自定义插件等。
Maven is the answer to a question no one asked. Writing an Ant script is not hard, and Ivy gives you better dependency management than Maven. I am confused by some of the previous comments stating they couldn't get Ivy working. Ivy is quite a bit simpler than Maven to get up and running.
Maven是一个没有人问过的问题的答案。编写Ant脚本并不难,Ivy为您提供比Maven更好的依赖管理。我对以前的一些评论感到困惑,说他们无法让常春藤工作。启动和运行Ivy比Maven简单得多。
The Spring Framework uses Ivy in its build process. I think that can be seen as quite a vote of confidence for Ivy.
Spring Framework在其构建过程中使用Ivy。我认为这可以被视为对常春藤的信任投票。
#4
7
I think this blog post covers exactly what the OP is looking for:
我认为这篇博文真正涵盖了OP所寻求的内容:
Why you should use the Maven Ant Tasks instead of Maven or Ivy
为什么你应该使用Maven Ant Tasks而不是Maven或Ivy
#5
7
If your long term goal is to migrate to using Maven to manage the entire build process (which one might intend to do for new greenfield projects), then I heartily recommend using Maven pom.xml files to manage dependencies on behalf of Ant build.xml files. The end result is that both your greenfield projects and your legacy projects are then all using the same mechanism to manage dependencies. And it turns out Maven really does a better job of managing dependencies for Ant build.xml files than does Ivy.
如果你的长期目标是迁移到使用Maven来管理整个构建过程(可能打算为新的绿地项目做什么),那么我衷心建议使用Maven pom.xml文件来代表Ant build.xml来管理依赖项。文件。最终结果是,您的绿地项目和遗留项目都使用相同的机制来管理依赖项。事实证明,Maven在管理Ant build.xml文件的依赖关系方面确实比Ivy更好。
Prior to adopting Maven as our flagship build tool, I had a developer attempt to use Ivy in combination to existing Ant build.xml files. This was most frustrating experience that very soon lead us to reject Ivy. We went ahead with an adoption of Maven. Our greenfield projects began to be built with the stock Maven approach, etc.
在采用Maven作为我们的旗舰构建工具之前,我让开发人员尝试将Ivy与现有的Ant build.xml文件结合使用。这是最令人沮丧的经历,很快导致我们拒绝常春藤。我们继续采用Maven。我们的绿地项目开始采用股票Maven方法等建立。
However, I went back to the Ant legacy projects and started using the Maven Ant task to define classpath definitions (and occasionally other Ant property definitions pulled in from the pom.xml). This turned out to be a most superlative experience. The existing Ant build.xml files need only be modified slightly to use Maven ant integration to define any classpath that were in use in the build.xml file. All dependencies required by the project became defined in an accompanying pom.xml file that gets processed by Maven via the Ant task incorporated into the build.xml files.
但是,我回到了Ant遗留项目并开始使用Maven Ant任务来定义类路径定义(有时还会从pom.xml中引入其他Ant属性定义)。结果证明这是一次*的体验。只需稍微修改现有的Ant build.xml文件,以使用Maven ant集成来定义build.xml文件中使用的任何类路径。项目所需的所有依赖项都在一个附带的pom.xml文件中定义,该文件由Maven通过整合到build.xml文件中的Ant任务进行处理。
Maven scopes can be used to fine tune classpath definitions such that one suitable for compiling, or running unit test, or for packaging, et al, can be established. Also, pretty much any element of something defined in the pom.xml file can be referenced as an Ant property within the build.xml file.
Maven范围可用于微调类路径定义,以便可以建立适合于编译,运行单元测试或包装等的定义。此外,几乎pom.xml文件中定义的任何元素都可以作为build.xml文件中的Ant属性引用。
Really with the Ant task for Maven there is no viable reason for Ivy to even exist.
对于Maven的Ant任务来说,没有任何可行的理由让Ivy存在。
#6
5
Comparing Maven with ivy/ant is to compare a smartphone to telegraphy.
将Maven与常春藤/蚂蚁进行比较是为了将智能手机与电报进行比较。
If you want to leverage a real enduring effect in your build infrastructure, it's better to use Maven because it anticipates and abstracts all processes and tasks every software project or other software-like project is faced with. I took part in many projects and if your projects get more complex and more diverse and more heterogeneous, you will praise even more the simplicity of a Maven project configuration. Indeed, it will become complex but not complicated compared to ivy/ant-driven projects.
如果您想在构建基础架构中利用真正持久的效果,最好使用Maven,因为它可以预测和抽象每个软件项目或其他类似软件项目所面临的所有流程和任务。我参与了许多项目,如果您的项目变得更复杂,更多样化,更多样化,您将更加赞赏Maven项目配置的简单性。实际上,与常春藤/蚂蚁驱动项目相比,它将变得复杂但并不复杂。
The main advantage of Maven is "convention over configuration" (http://en.wikipedia.org/wiki/Convention_over_configuration) a very important paradigm. In short, this means that you don't need to know/configure things that are obvious/trivial/commonplace. Although Maven and all its plugins ship with many default-settings, you always have the option to configure your projects for your special needs. With Maven, on the one hand you can setup a project very easy and quickly; on the other hand, you can customize a growing project up to your needs with minimum effort. If you have understood the key concepts behind Maven you will leverage every project and also projects that are not typical software development projects as well.
Maven的主要优点是“约定优于配置”(http://en.wikipedia.org/wiki/Convention_over_configuration)是一个非常重要的范例。简而言之,这意味着您不需要知道/配置明显/琐碎/普通的事物。虽然Maven及其所有插件都附带许多默认设置,但您始终可以选择根据您的特殊需求配置项目。使用Maven,一方面可以非常简单快捷地设置项目;另一方面,您可以轻松定制不断增长的项目,满足您的需求。如果您已经理解了Maven背后的关键概念,那么您将利用每个项目以及非典型软件开发项目的项目。
In the past, I wrote many ant scripts and with upcoming Maven I began to hate ant. One disadvantage is that you always copy scripts and repeat yourself, develop ant tasks that don't repeat tasks that don't repeat tasks that don't repeat... And the main disadvantage is that growing ant scripts tend to get unmaintainable, especially if a dozen ant geeks want to pimp up each others ant scripts.
在过去,我写了许多蚂蚁脚本,随着即将到来的Maven,我开始讨厌蚂蚁。一个缺点是你总是复制脚本并重复自己,开发不重复任务的ant任务,不重复不重复的任务......主要的缺点是不断增长的ant脚本往往难以维护,尤其是如果十几个蚂蚁怪人想要彼此掠夺蚂蚁脚本。
Many ant-enthusiasts suffer from getting overall control over trivial things like copying of artifacts and printing buildmessages. But because Maven's key concept is to hide these trivial things the legend will forever keep alive that Maven restricts customization needs. But don't worry, that’s a legend! And so you finally understand my initial statement: don't bother with trivial things that are already solved.
许多蚂蚁爱好者都会受到对诸如复制文物和打印构建消息等琐碎事物的全面控制。但是因为Maven的关键概念是隐藏这些琐碎的事物,传说将永远保持Maven限制定制需求。但不要担心,这是一个传奇!所以你终于理解了我的初步陈述:不要打扰已经解决的琐碎事情。
Maybe ivy/ant is an option for simple projects but for complex growing projects you need simplicity and conventions. Otherwise you will be overwhelmed with more and more maintaining problems. Especially if you have many dependent projects, technologies and heterogeneous product parts in a global project you don't have time and money for developing and testing ant scripts or solving dependency problems.
也许ivy / ant是简单项目的选择,但对于复杂的增长项目,您需要简单和惯例。否则你将面临越来越多的维护问题。特别是如果您在全球项目中有许多依赖项目,技术和异构产品部件,那么您就没有时间和金钱来开发和测试Ant脚本或解决依赖性问题。
Another advice should be mentioned: Ant offers the integration of Maven. This integration is often used to test and play with maven in projects that are grown up with ant. Avoid this stupid approach because it generates more problems. Instead stay with ant and its pain or migrate fully to maven.
应该提到另一个建议:Ant提供Maven的集成。这种集成通常用于在使用ant成长的项目中测试和使用maven。避免这种愚蠢的方法,因为它会产生更多问题。而是留在蚂蚁及其疼痛或完全迁移到maven。
If you are in doubt about the migration costs I suggest you to use the contrary way of integrating that different worlds by the Maven-Ant-Plugin. With this standard plugin you can run every ant-script without any effort. Sure it’s a legacy solution for a while, but it gives you as much time you need to understand mega-lines of monstrous distorted uncommented ant scripts of your predecessor.
如果您对迁移成本有疑问,我建议您使用Maven-Ant-Plugin集成不同世界的相反方式。使用此标准插件,您可以毫不费力地运行每个ant脚本。当然,它确实是一段时间的遗留解决方案,但它为您提供了所需的时间来理解前一代巨大的歪曲的未注释的蚂蚁脚本。
And now you will praise the next advantage of maven: You need very less documentation of your configuration, because documentation is part of every maven-plugin you want to use.
现在,您将赞扬maven的下一个优势:您需要的配置文档非常少,因为文档是您要使用的每个maven-plugin的一部分。
So I confess I was a Maven-Antagonist.
所以我承认我是一名Maven-Antagonist。
#7
2
I know that one advantage of Ivy is that it can use different kinds of repositories. Maven is typically very rigid in the format of the repository it will use. That's all I know.
我知道常春藤的一个优点是它可以使用不同类型的存储库。 Maven通常在其将使用的存储库格式中非常严格。这是我所知道的一切。
#8
1
I've just spent 2 days reading through the Ivy documentation and I have to say, USE MAVEN if you have any kind of choice. Ivy is complete and utter garbage as far as I can tell. I just wasted 2 days trying to incorporate it into my build and am cutting my losses now. Why?
我只花了两天阅读常春藤文档,我不得不说,如果你有任何选择,可以使用MAVEN。据我所知,常春藤是完整的,完全是垃圾。我只是浪费了2天试图将它融入我的构建中并且现在正在削减我的损失。为什么?
- Ivy is a half-assed attempt at dependency management
- Ivy documentation is a total joke
- Ivy examples and tutorial are useless
常春藤是依赖管理的一半尝试
常春藤文档是一个完全的笑话
常春藤的例子和教程都没用
As soon as I introduced 'configurations' (read as maven profiles), Ivy started going bezerk downloading all sorts of junk I don't need then failing. The documentation for Ivy is an utter joke. Maven documentation in comparison reads like a dream. If you want an example of how impenetrable and badly written the Ivy documentation is, take a look at the reference page for configurations. These are an essential part of any build, but in Ivy they seem to be a badly designed after thought.
一旦我介绍了'配置'(读作maven配置文件),Ivy开始下载各种垃圾,我不需要然后失败。常春藤的文档是一个彻头彻尾的笑话。相比之下,Maven文档就像一场梦。如果您想了解Ivy文档的难以理解和写得不好的示例,请查看配置的参考页面。这些是任何构建的重要组成部分,但在常春藤中,它们似乎是经过深思熟虑的设计。
#1
41
Since what you're wanting to do is add dependency management to an existing Ant project, that's precisely what Ivy's designed to do. Dependency management is a big part of Maven, but far from all of it. Maven is more of a project-oriented tool that does several other things in addition to dependencies. It would be worth considering if you were planning to migrate to Maven and use additional Maven features as well, but it's a bit much if all you'd use it for is to spin off Ant.
因为你想要做的是将依赖管理添加到现有的Ant项目中,这正是Ivy设计的目的。依赖管理是Maven的重要组成部分,但远非所有这些。 Maven更像是一个面向项目的工具,除了依赖之外还可以执行其他几项工作。如果您计划迁移到Maven并使用其他Maven功能,那将是值得考虑的,但是如果你所有人都使用它来分离Ant就有点多了。
Your type of dependencies and your expectations for how they behave will also make a difference. Pulling third-party dependencies is almost trivial in Maven, while Ivy excels in rebuilding your own dependent components. In either case, the tools won't provide decent build, versioning, and repository policies, those are still up to you and needed to get the configuration right.
您的依赖类型以及您对其行为方式的期望也会产生影响。在Maven中拉取第三方依赖关系几乎是微不足道的,而Ivy在重建自己的依赖组件方面表现出色。在任何一种情况下,这些工具都不会提供合适的构建,版本控制和存储库策略,这些仍然取决于您并且需要正确配置。
#2
40
Ant + Ivy == A campground, where people use the facilities as needed.
Maven == A resort, where you rely on someone else to provide services.
Ant + Ivy ==露营地,人们根据需要使用这些设施。 Maven ==一个度假胜地,您依靠别人提供服务。
Maven is easier for a team lacking build/integration experience, but when the team needs to diverge from Maven standards they will find themselves reaching for groovy, gradle, and the lack of solid documentation will become frustrating.
Maven对于缺乏构建/集成体验的团队来说更容易,但是当团队需要与Maven标准不同时,他们会发现自己正在接受groovy,gradle,缺乏可靠的文档会变得令人沮丧。
Ant + Ivy will take longer to startup a project, but if the team has build/integration experience they can tailor the build system around they way they develop and release code.
Ant + Ivy需要更长的时间来启动项目,但如果团队具有构建/集成经验,他们可以围绕他们开发和发布代码的方式定制构建系统。
In engineering... technology companies I always push for the campsite solution versus the resort.
在工程......技术公司,我总是推动营地解决方案而不是度假村。
It is amazing though that both Ant and Maven choose XML as their langauge to express build recipes with. The Java community is stuck on that XML...
令人惊讶的是,Ant和Maven都选择XML作为表达构建配方的语言。 Java社区坚持使用XML ...
#3
8
Ivy+Ant is far, far more flexible. Ivy does dependency management, period, and it does that extremely well, better than Maven. And with Ant you can pretty much put together any build system that you want.
常春藤+蚂蚁远远更灵活。 Ivy做了依赖管理,期间,它做得非常好,比Maven好。使用Ant,您可以将任何您想要的构建系统组合在一起。
Maven tries to control everything - the "lifecycle" (compile, test, package, etc.), where files should live, and so on. Have fun customizing plugins and the like if you don't like the "Maven way".
Maven试图控制一切 - “生命周期”(编译,测试,包等),文件应该存在的地方,等等。如果您不喜欢“Maven方式”,可以自定义插件等。
Maven is the answer to a question no one asked. Writing an Ant script is not hard, and Ivy gives you better dependency management than Maven. I am confused by some of the previous comments stating they couldn't get Ivy working. Ivy is quite a bit simpler than Maven to get up and running.
Maven是一个没有人问过的问题的答案。编写Ant脚本并不难,Ivy为您提供比Maven更好的依赖管理。我对以前的一些评论感到困惑,说他们无法让常春藤工作。启动和运行Ivy比Maven简单得多。
The Spring Framework uses Ivy in its build process. I think that can be seen as quite a vote of confidence for Ivy.
Spring Framework在其构建过程中使用Ivy。我认为这可以被视为对常春藤的信任投票。
#4
7
I think this blog post covers exactly what the OP is looking for:
我认为这篇博文真正涵盖了OP所寻求的内容:
Why you should use the Maven Ant Tasks instead of Maven or Ivy
为什么你应该使用Maven Ant Tasks而不是Maven或Ivy
#5
7
If your long term goal is to migrate to using Maven to manage the entire build process (which one might intend to do for new greenfield projects), then I heartily recommend using Maven pom.xml files to manage dependencies on behalf of Ant build.xml files. The end result is that both your greenfield projects and your legacy projects are then all using the same mechanism to manage dependencies. And it turns out Maven really does a better job of managing dependencies for Ant build.xml files than does Ivy.
如果你的长期目标是迁移到使用Maven来管理整个构建过程(可能打算为新的绿地项目做什么),那么我衷心建议使用Maven pom.xml文件来代表Ant build.xml来管理依赖项。文件。最终结果是,您的绿地项目和遗留项目都使用相同的机制来管理依赖项。事实证明,Maven在管理Ant build.xml文件的依赖关系方面确实比Ivy更好。
Prior to adopting Maven as our flagship build tool, I had a developer attempt to use Ivy in combination to existing Ant build.xml files. This was most frustrating experience that very soon lead us to reject Ivy. We went ahead with an adoption of Maven. Our greenfield projects began to be built with the stock Maven approach, etc.
在采用Maven作为我们的旗舰构建工具之前,我让开发人员尝试将Ivy与现有的Ant build.xml文件结合使用。这是最令人沮丧的经历,很快导致我们拒绝常春藤。我们继续采用Maven。我们的绿地项目开始采用股票Maven方法等建立。
However, I went back to the Ant legacy projects and started using the Maven Ant task to define classpath definitions (and occasionally other Ant property definitions pulled in from the pom.xml). This turned out to be a most superlative experience. The existing Ant build.xml files need only be modified slightly to use Maven ant integration to define any classpath that were in use in the build.xml file. All dependencies required by the project became defined in an accompanying pom.xml file that gets processed by Maven via the Ant task incorporated into the build.xml files.
但是,我回到了Ant遗留项目并开始使用Maven Ant任务来定义类路径定义(有时还会从pom.xml中引入其他Ant属性定义)。结果证明这是一次*的体验。只需稍微修改现有的Ant build.xml文件,以使用Maven ant集成来定义build.xml文件中使用的任何类路径。项目所需的所有依赖项都在一个附带的pom.xml文件中定义,该文件由Maven通过整合到build.xml文件中的Ant任务进行处理。
Maven scopes can be used to fine tune classpath definitions such that one suitable for compiling, or running unit test, or for packaging, et al, can be established. Also, pretty much any element of something defined in the pom.xml file can be referenced as an Ant property within the build.xml file.
Maven范围可用于微调类路径定义,以便可以建立适合于编译,运行单元测试或包装等的定义。此外,几乎pom.xml文件中定义的任何元素都可以作为build.xml文件中的Ant属性引用。
Really with the Ant task for Maven there is no viable reason for Ivy to even exist.
对于Maven的Ant任务来说,没有任何可行的理由让Ivy存在。
#6
5
Comparing Maven with ivy/ant is to compare a smartphone to telegraphy.
将Maven与常春藤/蚂蚁进行比较是为了将智能手机与电报进行比较。
If you want to leverage a real enduring effect in your build infrastructure, it's better to use Maven because it anticipates and abstracts all processes and tasks every software project or other software-like project is faced with. I took part in many projects and if your projects get more complex and more diverse and more heterogeneous, you will praise even more the simplicity of a Maven project configuration. Indeed, it will become complex but not complicated compared to ivy/ant-driven projects.
如果您想在构建基础架构中利用真正持久的效果,最好使用Maven,因为它可以预测和抽象每个软件项目或其他类似软件项目所面临的所有流程和任务。我参与了许多项目,如果您的项目变得更复杂,更多样化,更多样化,您将更加赞赏Maven项目配置的简单性。实际上,与常春藤/蚂蚁驱动项目相比,它将变得复杂但并不复杂。
The main advantage of Maven is "convention over configuration" (http://en.wikipedia.org/wiki/Convention_over_configuration) a very important paradigm. In short, this means that you don't need to know/configure things that are obvious/trivial/commonplace. Although Maven and all its plugins ship with many default-settings, you always have the option to configure your projects for your special needs. With Maven, on the one hand you can setup a project very easy and quickly; on the other hand, you can customize a growing project up to your needs with minimum effort. If you have understood the key concepts behind Maven you will leverage every project and also projects that are not typical software development projects as well.
Maven的主要优点是“约定优于配置”(http://en.wikipedia.org/wiki/Convention_over_configuration)是一个非常重要的范例。简而言之,这意味着您不需要知道/配置明显/琐碎/普通的事物。虽然Maven及其所有插件都附带许多默认设置,但您始终可以选择根据您的特殊需求配置项目。使用Maven,一方面可以非常简单快捷地设置项目;另一方面,您可以轻松定制不断增长的项目,满足您的需求。如果您已经理解了Maven背后的关键概念,那么您将利用每个项目以及非典型软件开发项目的项目。
In the past, I wrote many ant scripts and with upcoming Maven I began to hate ant. One disadvantage is that you always copy scripts and repeat yourself, develop ant tasks that don't repeat tasks that don't repeat tasks that don't repeat... And the main disadvantage is that growing ant scripts tend to get unmaintainable, especially if a dozen ant geeks want to pimp up each others ant scripts.
在过去,我写了许多蚂蚁脚本,随着即将到来的Maven,我开始讨厌蚂蚁。一个缺点是你总是复制脚本并重复自己,开发不重复任务的ant任务,不重复不重复的任务......主要的缺点是不断增长的ant脚本往往难以维护,尤其是如果十几个蚂蚁怪人想要彼此掠夺蚂蚁脚本。
Many ant-enthusiasts suffer from getting overall control over trivial things like copying of artifacts and printing buildmessages. But because Maven's key concept is to hide these trivial things the legend will forever keep alive that Maven restricts customization needs. But don't worry, that’s a legend! And so you finally understand my initial statement: don't bother with trivial things that are already solved.
许多蚂蚁爱好者都会受到对诸如复制文物和打印构建消息等琐碎事物的全面控制。但是因为Maven的关键概念是隐藏这些琐碎的事物,传说将永远保持Maven限制定制需求。但不要担心,这是一个传奇!所以你终于理解了我的初步陈述:不要打扰已经解决的琐碎事情。
Maybe ivy/ant is an option for simple projects but for complex growing projects you need simplicity and conventions. Otherwise you will be overwhelmed with more and more maintaining problems. Especially if you have many dependent projects, technologies and heterogeneous product parts in a global project you don't have time and money for developing and testing ant scripts or solving dependency problems.
也许ivy / ant是简单项目的选择,但对于复杂的增长项目,您需要简单和惯例。否则你将面临越来越多的维护问题。特别是如果您在全球项目中有许多依赖项目,技术和异构产品部件,那么您就没有时间和金钱来开发和测试Ant脚本或解决依赖性问题。
Another advice should be mentioned: Ant offers the integration of Maven. This integration is often used to test and play with maven in projects that are grown up with ant. Avoid this stupid approach because it generates more problems. Instead stay with ant and its pain or migrate fully to maven.
应该提到另一个建议:Ant提供Maven的集成。这种集成通常用于在使用ant成长的项目中测试和使用maven。避免这种愚蠢的方法,因为它会产生更多问题。而是留在蚂蚁及其疼痛或完全迁移到maven。
If you are in doubt about the migration costs I suggest you to use the contrary way of integrating that different worlds by the Maven-Ant-Plugin. With this standard plugin you can run every ant-script without any effort. Sure it’s a legacy solution for a while, but it gives you as much time you need to understand mega-lines of monstrous distorted uncommented ant scripts of your predecessor.
如果您对迁移成本有疑问,我建议您使用Maven-Ant-Plugin集成不同世界的相反方式。使用此标准插件,您可以毫不费力地运行每个ant脚本。当然,它确实是一段时间的遗留解决方案,但它为您提供了所需的时间来理解前一代巨大的歪曲的未注释的蚂蚁脚本。
And now you will praise the next advantage of maven: You need very less documentation of your configuration, because documentation is part of every maven-plugin you want to use.
现在,您将赞扬maven的下一个优势:您需要的配置文档非常少,因为文档是您要使用的每个maven-plugin的一部分。
So I confess I was a Maven-Antagonist.
所以我承认我是一名Maven-Antagonist。
#7
2
I know that one advantage of Ivy is that it can use different kinds of repositories. Maven is typically very rigid in the format of the repository it will use. That's all I know.
我知道常春藤的一个优点是它可以使用不同类型的存储库。 Maven通常在其将使用的存储库格式中非常严格。这是我所知道的一切。
#8
1
I've just spent 2 days reading through the Ivy documentation and I have to say, USE MAVEN if you have any kind of choice. Ivy is complete and utter garbage as far as I can tell. I just wasted 2 days trying to incorporate it into my build and am cutting my losses now. Why?
我只花了两天阅读常春藤文档,我不得不说,如果你有任何选择,可以使用MAVEN。据我所知,常春藤是完整的,完全是垃圾。我只是浪费了2天试图将它融入我的构建中并且现在正在削减我的损失。为什么?
- Ivy is a half-assed attempt at dependency management
- Ivy documentation is a total joke
- Ivy examples and tutorial are useless
常春藤是依赖管理的一半尝试
常春藤文档是一个完全的笑话
常春藤的例子和教程都没用
As soon as I introduced 'configurations' (read as maven profiles), Ivy started going bezerk downloading all sorts of junk I don't need then failing. The documentation for Ivy is an utter joke. Maven documentation in comparison reads like a dream. If you want an example of how impenetrable and badly written the Ivy documentation is, take a look at the reference page for configurations. These are an essential part of any build, but in Ivy they seem to be a badly designed after thought.
一旦我介绍了'配置'(读作maven配置文件),Ivy开始下载各种垃圾,我不需要然后失败。常春藤的文档是一个彻头彻尾的笑话。相比之下,Maven文档就像一场梦。如果您想了解Ivy文档的难以理解和写得不好的示例,请查看配置的参考页面。这些是任何构建的重要组成部分,但在常春藤中,它们似乎是经过深思熟虑的设计。