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: The Definitive Guide，我在介绍部分写了 Maven 和 Ant 之间的区别，部分标题是 "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/main/java 目录中的源代码编译到 target/classes 目录的 javac 任务.您必须准确地告诉 Ant 您的源在哪里，您希望将生成的字节码存储在哪里，以及如何将所有这些都打包到 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.

将前面的 Ant 示例与 Maven 示例进行对比.在 Maven 中，要从一些 Java 源创建 JAR 文件，您需要做的就是创建一个简单的 pom.xml，将源代码放在 ${basedir}/src/main/java 中，然后从命令行运行 mvn install.实现相同结果的示例 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 install 将处理资源、编译源代码、执行单元测试、创建 JAR 并将 JAR 安装在本地存储库中以便在其他项目中重用.无需修改，您可以运行 mvn site，然后在 target/site 中找到一个 index.html 文件，其中包含指向 JavaDoc 的链接和一些关于您的源代码的报告.

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.

诚然，这是最简单的示例项目.仅包含源代码并生成 JAR 的项目.遵循 Maven 约定且不需要任何依赖项或自定义的项目.如果我们想开始自定义行为，我们的 pom.xml 会变大，在最大的项目中，您可以看到非常复杂的 Maven POM 集合，其中包含大量插件自定义和依赖声明.但是，即使您的项目的 POM 文件变得更加庞大，它们也包含与使用 Ant 的类似大小项目的构建文件完全不同的信息.Maven POM 包含声明:这是一个 JAR 项目"和源代码在 src/main/java 中".Ant 构建文件包含明确的说明:这是项目"、源代码在 src/main/java"、针对此目录运行 javac"、将结果是 target/classses"、从 .... 创建一个 JAR"等等.在 Ant 必须明确说明过程的地方，Maven 有一些内置"的东西，只是知道源代码在哪里以及应该如何处理.

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 在哪里可以找到源代码以及在哪里放置输出.随着时间的推移，非正式惯例已经出现，但尚未编入产品中.
• 是程序性的，你必须准确地告诉 Ant 做什么以及什么时候做.你必须告诉它编译，然后复制，然后压缩.
• 没有生命周期，您必须定义目标和目标依赖项.您必须手动将一系列任务附加到每个目标.

Maven 在哪里...

Where Maven...

• 有约定，它已经知道你的源代码在哪里，因为你遵循了约定.它将字节码放在目标/类中，并在目标中生成一个 JAR 文件.
• 是声明性的.您所要做的就是创建一个 pom.xml 文件并将您的源代码放在默认目录中.Maven 负责其余的工作.
• 有一个生命周期，您在执行 mvn install 时会调用该生命周期.这个命令告诉 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.

常春藤怎么样?

是的，所以像 Steve Loughran 这样的人会阅读该比较并判罚犯规.他将谈论答案如何完全忽略称为 Ivy 的东西，以及 Ant 可以在最新版本的 Ant 中重用构建逻辑的事实.这是真的.如果你有一群聪明的人使用 Ant + antlibs + Ivy，你最终会得到一个设计良好、有效的构建.尽管如此，我非常相信 Maven 是有道理的，我很乐意将 Ant + Ivy 与一个拥有非常敏锐的构建工程师的项目团队一起使用.话虽如此，我确实认为您最终会错过许多有价值的插件，例如 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 更重要

1. 您是否使用存储库管理器来跟踪软件工件.我建议下载 Nexus.您可以使用 Nexus 代理远程代码库，并为您的团队提供部署内部工件的场所.
2. 您对软件组件进行了适当的模块化.一个大的单体组件很少随时间扩展.随着您的项目的发展，您将需要模块和子模块的概念.Maven 非常适合这种方法.
3. 您为构建采用了一些约定.即使您使用 Ant，您也应该努力采用与其他项目一致的某种形式的约定.当一个项目使用 Maven 时，这意味着任何熟悉 Maven 的人都可以选择构建并开始运行它，而无需为了弄清楚如何让事物进行编译而摆弄配置.

1. 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.
2. 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.
3. 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屋！