Ant和Maven之间的差异 [英] Differences between Ant and Maven
问题描述
有人能告诉我Ant和Maven之间的区别是什么？我从来没有或者是用。据我所知，他们是用于自动化的Java项目的建设，但我不知道从哪里开始。
Could someone tell me the differences between Ant and Maven? I have never used either. I understand that they are used to automate the building of Java projects, but I do not know where to start from.
推荐答案
在 Maven的：权威指南，我写在介绍Maven和蚂蚁之间的差异该部分的标题是<一个href=\"http://www.sonatype.com/books/maven-book/reference/installation-sect-compare-ant-maven.html\">\"The间Ant和Maven差异。这里有一个答案是与一些额外的指出，引入信息的组合。
In Maven: The Definitive Guide, I wrote about the differences between Maven and Ant in the introduction the section title is "The Differences Between Ant and Maven". Here's an answer that is a combination of the info in that introduction with some additional notes.
一个简单的比较
我只显示你这来说明的想法，在最基本的层次，Maven的有内置的公约。这里有一个简单的Ant构建文件：
I'm only showing you this to illustrate the idea that, at the most basic level, Maven has built-in conventions. Here's a simple Ant build file:
<project name="my-project" default="dist" basedir=".">
<description>
simple example build file
</description>
<!-- set global properties for this build -->
<property name="src" location="src/main/java"/>
<property name="build" location="target/classes"/>
<property name="dist" location="target"/>
<target name="init">
<!-- Create the time stamp -->
<tstamp/>
<!-- Create the build directory structure used by compile -->
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init"
description="compile the source " >
<!-- Compile the java code from ${src} into ${build} -->
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile"
description="generate the distribution" >
<!-- Create the distribution directory -->
<mkdir dir="${dist}/lib"/>
<!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file
-->
<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
</target>
<target name="clean"
description="clean up" >
<!-- Delete the ${build} and ${dist} directory trees -->
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>
在这个简单的Ant例子，你可以看到你怎么也得告诉Ant该怎么做。有一个编译目标，其中包括的源码编译在src /主/ java目录到目标/ classes目录javac任务。你要告诉Ant正是你的来源是，在那里你要存储生成的字节code，以及如何包装这一切到一个JAR文件。虽然有一些帮助Ant减少程序的最新发展，开发者对Ant的感受是用XML编写程序语言。
In this simple Ant example, you can see how you have to tell Ant exactly what to do. There is a compile goal which includes the javac task that compiles the source in the src/main/java directory to the target/classes directory. You have to tell Ant exactly where your source is, where you want the resulting bytecode to be stored, and how to package this all into a JAR file. While there are some recent developments that help make Ant less procedural, a developer's experience with Ant is in coding a procedural language written in XML.
有一个Maven的例子对比previous蚂蚁的例子。 Maven中，要从Java源码创建一个JAR文件，你需要做的是创建一个简单的pom.xml，将你的源$ C $ C $中{} BASEDIR / SRC / main / java下，然后运行MVN从安装命令行。这个例子的Maven pom.xml的是达到了相同的结果。
Contrast the previous Ant example with a Maven example. In Maven, to create a JAR file from some Java source, all you need to do is create a simple pom.xml, place your source code in ${basedir}/src/main/java and then run mvn install from the command line. The example Maven pom.xml that achieves the same results.
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>my-project</artifactId>
<version>1.0</version>
</project>
这就是你在你的pom.xml的需要。 MVN运行在命令行安装将处理资源，编译源代码，运行单元测试，创建一个JAR，并在本地存储库中其他项目的再利用安装JAR。无需修改，你可以运行mvn网站，然后找到目标/网站的index.html文件包含链接到JavaDoc和一些关于源$ C $ C少数报道。
That's all you need in your pom.xml. Running mvn install from the command line will process resources, compile source, execute unit tests, create a JAR, and install the JAR in a local repository for reuse in other projects. Without modification, you can run mvn site and then find an index.html file in target/site that contains links to JavaDoc and a few reports about your source code.
诚然，这是最简单的可能的例子的项目。其中只包含源$ C $ c和它的项目产生一个JAR。它遵循Maven的约定，并且不需要任何依赖和定制的项目。如果我们想要定制行为，我们的pom.xml打算扩大规模，并在最大的项目中，你可以看到包含插件定制和依赖声明大量非常复杂的Maven金属氧酸盐的集合。但是，即使当你的项目的POM文件变得更充实，他们持有一种完全不同的，从使用Ant一个同样大小的项目的构建文件的信息。 Maven的金属氧酸盐包含的声明：这是一个JAR项目和源$ C $ C在src / main / java目录。 Ant构建文件包含明确的指示：这是项目，源代码在的src / main / JAVA ，润的javac 此目录，把目标/ classses结果对，创建自......，等等。Ant必须到JAR更明确一些程序，有一些内置到Maven的，仅仅知道其中源$ C $ C是它应如何处理。
Admittedly, this is the simplest possible example project. A project which only contains source code and which produces a JAR. A project which follows Maven conventions and doesn't require any dependencies or customization. If we wanted to start customizing the behavior, our pom.xml is going to grow in size, and in the largest of projects you can see collections of very complex Maven POMs which contain a great deal of plugin customization and dependency declarations. But, even when your project's POM files become more substantial, they hold an entirely different kind of information from the build file of a similarly sized project using Ant. Maven POMs contain declarations: "This is a JAR project", and "The source code is in src/main/java". Ant build files contain explicit instructions: "This is project", "The source is in src/main/java", "Run javac against this directory", "Put the results in target/classses", "Create a JAR from the ....", etc. Where Ant had to be explicit about the process, there was something "built-in" to Maven that just knew where the source code was and how it should be processed.
高层比较
在这个例子中Ant和Maven之间的区别是什么？蚂蚁...
The differences between Ant and Maven in this example? Ant...
- 没有正式的约定如一个一般项目的目录结构，你必须明确的告诉Ant哪里可以找到源头，并在那里把输出。非正式公约已经出现一段时间，但他们没有被编入该产品。
- 是程序性的，你要告诉蚂蚁到底该怎么做，什么时候做。你必须告诉它来编译，然后复制，那么COM preSS。
- 没有一个生命周期，你必须定义目标和目标之间的依赖。你必须手动附加任务，每一个目标的序列。
在哪里Maven的...
Where Maven...
- 有公约，它已经知道在您的源$ C $ C是因为你遵循的惯例。它把字节code在目标/班，它产生于目标的JAR文件。
- 是声明。所有你所要做的就是创建一个pom.xml文件然后将源代码中的默认目录。 Maven会帮你处理剩下的事情。
- 都有一个生命周期，当你执行
MVN安装您激活。这条命令告诉Maven的，直到它达到生命周期执行一系列的顺序步骤。由于这旅程，通过生命周期的一个副作用就是，Maven运行了许多该做的事情一样编译和创建一个JAR默认插件的目标。
- has conventions, it already knew where your source code was because you followed the convention. It put the bytecode in target/classes, and it produced a JAR file in target.
- is declarative. All you had to do was create a pom.xml file and put your source in the default directory. Maven took care of the rest.
- has a lifecycle, which you invoked when you executed
mvn install. This command told Maven to execute a series of sequence steps until it reached the lifecycle. As a side-effect of this journey through the lifecycle, Maven executed a number of default plugin goals which did things like compile and create a JAR.
什么关于艾维？
对，所以有人喜欢史蒂夫劳伦是要读的比较和呼叫犯规。他会谈论如何回答完全忽略所谓常青藤和事实，蚂蚁可以在蚂蚁的更新的版本中重用构建逻辑。这是真的。如果你有一堆使用Ant + antlibs +常春藤聪明的人，你会用一个精心设计建造，工程结束。虽然，我非常相信，Maven的有道理，我会高兴地使用Ant +艾维与项目团队，有一个非常尖锐的构建工程师。话虽这么说，我不认为你会最终对一些有价值的插件，如Jetty插件，而且你最终做的工作一大堆，你并不需要做一段时间。缺少了
Right, so someone like Steve Loughran is going to read that comparison and call foul. He's going to talk about how the answer completely ignores something called Ivy and the fact that Ant can reuse build logic in the more recent releases of Ant. This is true. If you have a bunch of smart people using Ant + antlibs + Ivy, you'll end up with a well designed build that works. Even though, I'm very much convinced that Maven makes sense, I'd happily use Ant + Ivy with a project team that had a very sharp build engineer. That being said, I do think you'll end up missing out on a number of valuable plugins such as the Jetty plugin and that you'll end up doing a whole bunch of work that you didn't need to do over time.
比Maven和Ant的更重要
- 是您使用一个仓库管理器来跟踪软件制品。我建议下载的Nexus 。您可以使用的Nexus代理远程存储库，并为您的团队内部部署文物的地方。
- 您有软件组件的模块化合适。一个大的整体结构件很少尺度随着时间的推移。随着项目的发展，你想拥有的模块和子模块的概念。 Maven的适合于这种方法很好。
- 您采用一些约定构建。即使你使用Ant，你应该努力采取某种形式的约定是与其他项目相一致。当一个项目使用Maven的，这意味着任何人都熟悉的Maven可以拿起建立和开始使用它运行，而不必与配置捣鼓只是为了弄清楚如何去编译的东西。
- Is that you use a Repository Manager to keep track of software artifacts. I'd suggest downloading Nexus. You can use Nexus to proxy remote repositories and to provide a place for your team to deploy internal artifacts.
- You have appropriate modularization of software components. One big monolithic component rarely scales over time. As your project develops, you'll want to have the concept of modules and sub-modules. Maven lends itself to this approach very well.
- You adopt some conventions for your build. Even if you use Ant, you should strive to adopt some form of convention that is consistent with other projects. When a project uses Maven, it means that anyone familiar with Maven can pick up the build and start running with it without having to fiddle with configuration just to figure out how to get the thing to compile.
这篇关于Ant和Maven之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
