1. Introducing Apache Maven

1.1. Maven… What is it?

The answer to this question depends on your own perspective. The great majority of Maven users are going to call Maven a “build tool”: a tool used to build deployable artifacts from source code. Build engineers and project managers might refer to Maven as something more comprehensive: a project management tool. What is the difference? A build tool such as Ant is focused solely on preprocessing, compilation, packaging, testing, and distribution. A project management tool such as Maven provides a superset of features found in a build tool. In addition to providing build capabilities, Maven can also run reports, generate a web site, and facilitate communication among members of a working team.

这个问题的答案取决于您自己的观点。 大多数Maven用户将Maven称为“构建工具”：一种用于从源代码构建可部署工件的工具。 运维工程师和项目经理可能将Maven称为更全面的东西：项目管理工具。 有什么区别？ 诸如Ant之类的构建工具仅专注于预处理，编译，打包，测试和分发。 诸如Maven之类的项目管理工具提供了在构建工具中发现的功能的超集。 除了提供构建功能外，Maven还可以运行报告，生成网站并促进工作团队成员之间的沟通。

A more formal definition of Apache Maven: Maven is a project management tool which encompasses a project object model, a set of standards, a project lifecycle, a dependency management system, and logic for executing plugin goals at defined phases in a lifecycle. When you use Maven, you describe your project using a well-defined project object model, Maven can then apply cross-cutting logic from a set of shared (or custom) plugins.

Apache Maven的一个更正式的定义：Maven是一个项目管理工具，它包含一个项目对象模型，一组标准，一个项目生命周期，一个依赖关系管理系统以及在生命周期的定义阶段执行插件目标的逻辑。 使用Maven时，您可以使用定义明确的项目对象模型描述项目，然后Maven可以从一组共享（或自定义）插件中应用跨领域逻辑。

Don’t let the fact that Maven is a “project management” tool scare you away. If you were just looking for a build tool, Maven will do the job. In fact, the first few chapters of this book will deal with the most common use case: using Maven to build and distribute your project.

不要让Maven是“项目管理”工具这一事实吓到您了。 如果您只是在寻找构建工具，Maven会做的。 实际上，本书的前几章将介绍最常见的用例：使用Maven构建和分发项目。

1.2. Convention Over Configuration

Convention over configuration is a simple concept: Systems, libraries, and frameworks should assume reasonable defaults. Without requiring unnecessary configuration, systems should “just work”. Popular frameworks such as Ruby on Rails and EJB3 have started to adhere to these principles in reaction to the configuration complexity of frameworks such as the initial EJB 2.1 specifications. An illustration of convention over configuration is something like EJB3 persistence: all you need to do to make a particular bean persistent is to annotate that class with @Entity. The framework assumes table and column names based on the name of the class and the names of the properties. Hooks are provided for you to override these default, assumed names if the need arises, but, in most cases, you will find that using the framework-supplied defaults results in a faster project execution.

约定优于配置是一个简单的概念：系统，库和框架应采用合理的默认值。 在不需要不必要的配置的情况下，系统应该“正常工作”。 诸如Ruby on Rails和EJB3之类的流行框架已经开始遵守这些原则，以应对诸如初始EJB 2.1规范之类的框架的配置复杂性。 关于配置的约定的说明类似于EJB3持久性：使特定bean持久化所需要做的就是用@Entity注释该类。 该框架基于类的名称和属性的名称假定表和列的名称。 提供了挂钩，以便您在需要时覆盖这些默认的假定名称，但是，在大多数情况下，您会发现使用框架提供的默认值可以更快地执行项目。

Maven incorporates this concept by providing sensible default behavior for projects. Without customization, source code is assumed to be in ${basedir}/src/main/java and resources are assumed to be in ${basedir}/src/main/resources. Tests are assumed to be in ${basedir}/src/test, and a project is assumed to produce a JAR file. Maven assumes that you want the compile bytecode to ${basedir}/target/classes and then create a distributable JAR file in ${basedir}/target. While this might seem trivial, consider the fact that most Ant-based builds have to define the locations of these directories. Ant doesn’t ship with any built-in idea of where source code or resources might be in a project; you have to supply this information. Maven’s adoption of convention over configuration goes farther than just simple directory locations. Maven’s core plugins apply a common set of conventions for compiling source code, packaging distributions, generating web sites, and many other processes. Maven’s strength comes from the fact that it is “opinionated”; it has a defined life-cycle and a set of common plugins that know how to build and assemble software. If you follow the conventions, Maven will require almost zero effort - just put your source in the correct directory, and Maven will take care of the rest.

Maven通过为项目提供明智的默认行为来结合了这一概念。如果不进行定制，则假定源代码位于src/main/java中，而资源则位于src/main/resources中。假定测试位于src/test中，并且假定项目产生了一个JAR文件。 Maven假定您希望将编译字节码编译为target/classes，然后在target中创建可分发的JAR文件。尽管这似乎微不足道，但请考虑以下事实：大多数基于Ant的构建都必须定义这些目录的位置。 Ant并没有内置任何关于源代码或资源可能在项目中的位置的想法；您必须提供此信息。 Maven在配置上采用约定的方法远不只是简单的目录位置。 Maven的核心插件采用了一套通用的约定，用于编译源代码，打包发行版，生成网站以及许多其他过程。 Maven的实力来自于它被“精选”的事实。它具有定义的生命周期和一组知道如何构建和组装软件的常用插件。如果遵循这些约定，Maven将几乎不需要花费任何精力-只需将您的源代码放在正确的目录中，其余的工作将由Maven负责。

One side effect of using systems that follow “convention over configuration” is that end-users might feel that they are forced to use a particular methodology or approach. While it is certainly true that Maven has some core opinions that shouldn’t be challenged, most of the defaults can be customized. For example, the location of a project’s source code and resources can be customized, names of JAR files can be customized, and through the development of custom plugins, almost any behavior can be tailored to your specific environment’s requirements. If you don’t care to follow convention, Maven will allow you to customize defaults in order to adapt to your specific requirements.

使用遵循“惯例超越配置”的系统的一个副作用是，最终用户可能会感到自己被迫使用特定的方法论或方法。 虽然Maven确实有一些不容质疑的核心观点，但是大多数默认值都可以自定义。 例如，可以自定义项目源代码和资源的位置，可以自定义JAR文件的名称，并且通过开发自定义插件，几乎任何行为都可以根据您特定环境的要求进行定制。 如果您不想遵循约定，Maven将允许您自定义默认值，以适应您的特定要求。

1.3. A Common Interface

Before Maven provided a common interface for building software, every single project had someone dedicated to managing a fully customized build system. Developers had to take time away from developing software to learn about the idiosyncrasies of each new project they wanted to contribute to. In 2001, you’d have a completely different approach to building a project like Turbine than you would to building a project like Tomcat. If a new source code analysis tool came out that would perform static analysis on source code, or if someone developed a new unit testing framework, everybody would have to drop what they were doing and figure out how to fit it into each project’s custom build environment. How do you run unit tests? There were a thousand different answers. This environment was characterized by a thousand endless arguments about tools and build procedures. The age before Maven was an age of inefficiency, the age of the “Build Engineer”.

在Maven提供用于构建软件的通用界面之前，每个项目都有专门负责管理完全定制的构建系统的人员。 开发人员必须花时间去开发软件，以了解他们想贡献的每个新项目的特质。 在2001年，您将采用完全不同的方法来构建类似Turbine的项目，而不是构建像Tomcat这样的项目。 如果一个新的源代码分析工具问世，它将对源代码进行静态分析，或者如果有人开发了一个新的单元测试框架，那么每个人都必须放弃正在做的事情，并弄清楚如何将其适合每个项目的自定义构建环境。 。 您如何运行单元测试？ 有千种不同的答案。 这种环境的特征是关于工具和构建过程的一千种无休止的争论。 Maven之前的时代是效率低下的时代，即“建筑工程师”的时代。

Today, most open source developers have used or are currently using Maven to manage new software projects. This transition is less about developers moving from one build tool to another and more about developers starting to adopt a common interface for project builds. As software systems have become more modular, build systems have become more complex, and the number of projects has skyrocketed. Before Maven, when you wanted to check out a project like Apache ActiveMQ or Apache ServiceMix from Subversion and build it from source, you really had to set aside about an hour to figure out the build system for each particular project. What does the project need to build? What libraries do I need to download? Where do I put them? What goals can I execute in the build? In the best case, it took a few minutes to figure out a new project’s build, and in the worst cases (like the old Servlet API implementation in the Jakarta Project), a project’s build was so difficult it would take multiple hours just to get to the point where a new contributor could edit source and compile the project. These days, you check it out from source, and you run mvn install.

今天，大多数开源开发人员已经使用或正在使用Maven来管理新的软件项目。这种过渡与开发人员从一种构建工具迁移到另一种构建工具无关，而更多地是与开发人员开始为项目构建采用通用接口有关。随着软件系统变得更加模块化，构建系统变得越来越复杂，项目数量猛增。在Maven之前，当您想从Subversion检出Apache ActiveMQ或Apache ServiceMix之类的项目并从源代码进行构建时，您确实必须花一个小时来弄清楚每个特定项目的构建系统。该项目需要建造什么？我需要下载哪些库？我该放在哪里？我可以在构建中执行哪些目标？在最佳情况下，花了几分钟时间才能确定新项目的构建，而在最坏情况下（例如Jakarta Project中的旧Servlet API实现），项目的构建是如此困难，以至于要花费数小时才能获得到新的贡献者可以编辑源代码并编译项目的地步。这些天，您从源代码中签出，然后运行mvn install。

While Maven provides an array of benefits including dependency management and reuse of common build logic through plugins, the core reason why it has succeeded is that it has defined a common interface for building software. When you see that a project like Apache ActiveMQ uses Maven, you can assume that you’ll be able to check it out from source and build it with mvn install without much hassle. You know where the ignition keys goes, you know that the gas pedal is on the right side, and the brake is on the left.

虽然Maven提供了一系列好处，包括依赖性管理和通过插件重用常见的构建逻辑，但其成功的核心原因是它已定义了用于构建软件的通用接口。 当您看到类似Apache ActiveMQ的项目使用Maven时，可以假定您将能够从源代码中检出该项目并使用mvn install进行构建，而不会麻烦。 您知道点火钥匙在哪里，您知道油门在右侧，而制动器在左侧。

1.4. Universal Reuse through Maven Plugins

Plugins are more than just a trick to minimize the download size of the Maven distribution. Plugins add new behavior to your project’s build. Maven retrieves both dependencies and plugins from the remote repository, allowing for universal reuse of build logic.

插件不仅仅是使Maven发行版的下载大小最小化的一种技巧。 插件会在您的项目的构建中添加新的行为。 Maven从远程存储库中检索依赖项和插件，从而可以通用地重用构建逻辑。

The Maven Surefire plugin is the plugin that is responsible for running unit tests. Somewhere between version 1.0 and the version that is in wide use today someone decided to add support for the TestNG unit testing framework in addition to the support for JUnit. This upgrade happened in a way that didn’t break backwards compatibility. If you were using the Surefire plugin to compile and execute JUnit 3 unit tests, and you upgraded to the most recent version of the Surefire plugin, your tests continued to execute without fail. But, you gained new functionality; if you want to execute unit tests in TestNG you now have that ability. You also gained the ability to run annotated JUnit 4 unit tests. You gained all of these capabilities without having to upgrade your Maven installation or install new software. Most importantly, nothing about your project had to change aside from a version number for a plugin in a single Maven configuration file called the Project Object Model (POM).

Maven Surefire插件是负责运行单元测试的插件。 在版本1.0和今天广泛使用的版本之间，有人决定除了对JUnit的支持之外，还添加对TestNG单元测试框架的支持。 升级的方式不会破坏向后兼容性。 如果您使用Surefire插件来编译和执行JUnit 3单元测试，并且已升级到Surefire插件的最新版本，则测试将继续执行而不会失败。 但是，您获得了新功能； 如果您想在TestNG中执行单元测试，则现在可以使用该功能。 您还获得了运行带注释的JUnit 4单元测试的功能。 您获得了所有这些功能，而不必升级Maven安装或安装新软件。 最重要的是，除了在单个Maven配置文件中称为项目对象模型（POM）的插件的版本号之外，您的项目的任何内容都无需更改。

It is this mechanism that affects much more than the Surefire plugin. Maven has plugins for everything from compiling Java code, to generating reports, to deploying to an application server. Maven has abstracted common build tasks into plugins which are maintained centrally and shared universally. If the state-of-the-art changes in any area of the build, if some new unit testing framework is released or if some new tool is made available, you don’t have to be the one to hack your project’s custom build system to support it. You benefit from the fact that plugins are downloaded from a remote repository and maintained centrally. This is what is meant by universal reuse through Maven plugins.

这种机制的影响远不止Surefire插件。 Maven的插件涵盖了从编译Java代码到生成报告，再到部署到应用程序服务器的所有内容。 Maven已将常见的构建任务抽象到可集中维护和通用共享的插件中。 如果在构建的任何方面都进行了最新的更改，发布了一些新的单元测试框架或提供了一些新的工具，则您不必成为破解项目自定义构建系统的人。 支持它。 您将从插件从远程存储库下载并集中维护这一事实中受益。 这就是通过Maven插件进行通用重用的意思。

1.5. Conceptual Model of a “Project”

Maven maintains a model of a project. You are not just compiling source code into bytecode, you are developing a description of a software project and assigning a unique set of coordinates to a project. You are describing the attributes of the project. What is the project’s license? Who develops and contributes to the project? What other projects does this project depend upon? Maven is more than just a “build tool”, it is more than just an improvement on tools like make and Ant, it is a platform that encompasses a new semantics related to software projects and software development.

Maven维护项目模型。 您不只是将源代码编译成字节码，还正在开发软件项目的描述，并为项目分配唯一的坐标集。 您正在描述项目的属性。 该项目的许可证是什么？ 谁开发并为该项目做出贡献？ 该项目还依赖其他哪些项目？ Maven不仅是“构建工具”，还不仅仅是对make和Ant等工具的改进，它是一个包含与软件项目和软件开发有关的新语义的平台。

This definition of a model for every project enables such features as:

• Dependency Management 依赖管理
  Because a project is defined by a unique set of coordinates consisting of a group identifier, an artifact identifier, and a version, projects can now use these coordinates to declare dependencies.

  因为项目是由一组唯一的坐标定义的，这些坐标由组标识符，项目标识符和版本组成，所以项目现在可以使用这些坐标来声明依赖项。

• Remote Repositories 远程仓库
  Related to dependency management, we can use the coordinates defined in the Maven Project Object Model (POM) to create repositories of Maven artifacts.

  与依赖项管理有关，我们可以使用在Maven项目对象模型（POM）中定义的坐标来创建Maven工件的存储库。

• Universal Reuse of Build Logic 通用重用构建逻辑
  Plugins contain logic that works with the descriptive data and configuration parameters defined in Project Object Model (POM); they are not designed to operate upon specific files in known locations.

  插件包含与项目对象模型（POM）中定义的描述性数据和配置参数一起使用的逻辑； 它们并非旨在对已知位置的特定文件进行操作。

• Tool Portability / Integration 工具的可移植性/集成
  Tools like Eclipse, NetBeans, and IntelliJ now have a common place to find information about a project. Before the advent of Maven, every IDE had a different way to store what was essentially（本质上） a custom Project Object Model (POM). Maven has standardized this description, and while each IDE continues to maintain custom project files, they can be easily generated from the model.

  现在，诸如Eclipse，NetBeans和IntelliJ之类的工具在查找项目信息方面具有普遍的地位。 在Maven出现之前，每个IDE都有一种不同的存储本质（本质上）的自定义项目对象模型（POM）的方法。 Maven已对此描述进行了标准化，并且尽管每个IDE继续维护自定义项目文件，但可以轻松地从模型中生成它们。

• Easy Searching and Filtering of Project Artifacts 轻松搜索和过滤项目工件
  Tools like Nexus allow you to index and search the contents of a repository using the information stored in the POM.

  Nexus之类的工具使您可以使用POM中存储的信息来索引和搜索存储库的内容。

1.6. Is Maven an alternative to XYZ?

So, sure, Maven is an alternative to Ant, but Apache Ant continues to be a great, widely-used tool. It has been the reigning champion of Java builds for years, and you can integrate Ant build scripts with your project’s Maven build very easily. This is a common usage pattern for a Maven project. On the other hand, as more and more open source projects move to Maven as a project management platform, working developers are starting to realize that Maven not only simplifies the task of build management, it is helping to encourage a common interface between developers and software projects. Maven is more of a platform than a tool, while you could consider Maven an alternative to Ant, you are comparing apples to oranges. “Maven” includes more than just a build tool.

因此，可以肯定的是，Maven是Ant的替代产品，但是Apache Ant仍然是一个出色的，广泛使用的工具。 多年来，它一直是Java构建的领导者，您可以非常轻松地将Ant构建脚本与项目的Maven构建集成在一起。 这是Maven项目的常用用法。 另一方面，随着越来越多的开源项目迁移到Maven作为项目管理平台，正在工作的开发人员开始意识到Maven不仅简化了构建管理的任务，而且还有助于鼓励开发人员与软件之间的通用接口。 项目。 Maven更像是平台而非工具，虽然您可以将Maven视为Ant的替代品，但您正在将苹果与桔子进行比较。 “ Maven”不仅包含构建工具。

This is the central point that makes all of the Maven vs. Ant, Maven vs. Buildr, Maven vs. Gradle arguments irrelevant . Maven isn’t totally defined by the mechanics of your build system. It isn’t about scripting the various tasks in your build as much as it is about encouraging a set of standards, a common interface, a life-cycle, a standard repository format, a standard directory layout, etc. It certainly isn’t about what format the POM happens to be in (XML vs. YAML vs. Ruby). Maven is much larger than that, and Maven refers to much more than the tool itself. When this book talks of Maven, it is referring to the constellation of software, systems, and standards that support it. Buildr, Ivy, Gradle, all of these tools interact with the repository format that Maven helped create, and you could just as easily use a repository manager like Nexus to support a build written entirely in Ant.

这是使所有Maven与Ant，Maven与Buildr，Maven与Gradle参数无关的中心点。 Maven并非完全由构建系统的机制定义。 与鼓励建立一组标准，一个通用界面，一个生命周期，一个标准存储库格式，一个标准目录布局等有关，并不是要在构建中编写各种任务的脚本。它当然不是 关于POM恰好采用的格式（XML，YAML和Ruby）。 Maven的功能远不止于此，Maven所指的不仅仅是工具本身。 当本书谈到Maven时，它指的是支持它的软件，系统和标准的体系。 Buildr，Ivy，Gradle，所有这些工具都与Maven帮助创建的存储库格式交互，您可以轻松地使用Nexus之类的存储库管理器来支持完全用Ant编写的构建。

While Maven is an alternative to many of these tools, the community needs to evolve beyond seeing technology as a zero-sum game between unfriendly competitors in a competition for users and developers. This might be how large corporations relate to one another, but it has very little relevance to the way that open source communities work. The headline “Who’s winning? Ant or Maven?” isn’t very constructive. If you force us to answer this question, we’re definitely going to say that Maven is a superior alternative to Ant as a foundational technology for a build; at the same time, Maven’s boundaries are constantly shifting and the Maven community is constantly trying to seek out new ways to become more ecumenical, more inter-operable, more cooperative. The core tenets of Maven are declarative builds, dependency management, repository managers, and universal reuse through plugins, but the specific incarnation of these ideas at any given moment is less important than the sense that the open source community is collaborating to reduce the inefficiency of “enterprise-scale builds”.

尽管Maven是许多工具的替代品，但社区需要不断发展，而不仅仅是将技术视为不友好的竞争对手之间的零和游戏，以竞争用户和开发人员。这可能是大型公司之间相互联系的方式，但与开源社区的工作方式没有多大关系。标题“谁赢了？Ant还是Maven？”不太有建设性。如果您强迫我们回答这个问题，那么我们肯定会说Maven是Ant作为构建基础技术的替代品。同时，Maven的边界在不断变化，Maven社区也在不断尝试寻找新方法，以变得更加普世，更可互操作，更合作。 Maven的核心原则是声明性构建，依赖关系管理，存储库管理器和通过插件的通用重用，但是在任何给定时刻，这些思想的具体化身都没有开源社区正在共同努力以减少效率低下的意义重要。 “企业规模的构建”。

1.7. Comparing Maven with Ant

The authors of this book have no interest in creating a feud between Apache Ant and Apache Maven, but we are also cognizant of the fact that most organizations have to make a decision between the two standard solutions: Apache Ant and Apache Maven. In this section, we compare and contrast the tools.

本书的作者没有兴趣在Apache Ant和Apache Maven之间产生争执，但是我们也意识到大多数组织必须在两种标准解决方案（Apache Ant和Apache Maven）之间做出决定这一事实。 在本节中，我们将比较和对比这些工具。

Ant excels at build process; it is a build system modeled after make with targets and dependencies. Each target consists of a set of instructions which are coded in XML. There is a copy task and a javac task as well as a jar task. When you use Ant, you supply Ant with specific instructions for compiling and packaging your output.

Ant擅长构建过程； 它是一个在make之后使用目标和依赖项建模的构建系统。 每个目标都包含一组定义在XML的指令。 有一个复制任务和一个Javac任务以及一个jar任务。 使用Ant时，将为Ant提供编译和打包输出的特定说明。

Look at the following example of a simple build.xml file:

A Simple Ant build.xml 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"/>
    
        <!-- Ouput into ${build} into a 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>

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示例中，您可以看到如何准确地告诉Ant该做什么。 有一个编译目标，其中包括javac任务，该任务将src / main / java目录中的源编译为target / classes目录。 您必须确切地告诉Ant源所在的位置，想要将生成的字节码存储在哪里以及如何将所有这些打包到JAR文件中。 尽管最近有一些开发可以帮助减少Ant的过程，但是开发人员在Ant方面的经验是编码用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 as the simple Ant file listed in A Simple Ant build.xml File is shown in A Sample Maven pom.xml.

将之前的Ant示例与Maven示例进行对比。 在Maven中，要从某些Java源代码创建JAR文件，您需要做的就是创建一个简单的pom.xml，将源代码放在$ {basedir} / src / main / java中，然后从命令行运行mvn install 。以下pom.xml中显示了示例Maven pom.xml，该示例可实现与A Simple Ant build.xml File文件中列出的简单Ant文件相同的结果。

A Sample Maven pom.xml.

    <project>
      <modelVersion>4.0.0</modelVersion>
      <groupId>org.sonatype.mavenbook</groupId>
      <artifactId>my-project</artifactId>
      <version>1.0-SNAPSHOT</version>
    </project>

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.

这就是您pom.xml中所需的全部。 从命令行运行mvn install将处理资源，编译源代码，执行单元测试，创建JAR并将JAR安装在本地存储库中以在其他项目中重用。 无需修改，您可以运行mvn site，然后在target / site中找到一个index.html文件，其中包含指向JavaDoc的链接以及一些有关源代码的报告。

Admittedly, this is the simplest possible example project containing nothing more than some source code and producing a simple JAR. It is a project which closely 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/classes”, “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.

诚然，这是最简单的示例项目，仅包含一些源代码并生成一个简单的JAR。这是一个严格遵循Maven约定的项目，不需要任何依赖项或自定义项。如果我们要开始自定义行为，则pom.xml的大小将不断增长，在最大的项目中，您会看到非常复杂的Maven POM的集合，其中包含大量的插件自定义和依赖项声明。但是，即使您的项目的POM文件越来越重要，它们所保存的信息也与使用Ant的类似大小的项目的构建文件完全不同。 Maven POM包含以下声明：“这是一个JAR项目”和“源代码在src / main / java中”。 Ant构建文件包含明确的指令：“这是项目”，“源位于src / main / java中”，“针对此目录运行javac”，“将结果放入目标/类中”，“从…创建JAR …等等。在必须明确说明Ant的过程中，Maven有一些“内置”功能，它只是知道源代码在哪里以及应该如何处理它。

The differences between Ant and Maven in this example are:

• Apache Ant
  Ant doesn’t have formal conventions like a common project directory structure or default behavior. You have to tell Ant exactly where to find the source and where to put the output. Informal conventions have emerged over time, but they haven’t been codified into the product.Ant is procedural. You have to tell Ant exactly what to do and when to do it. You have to tell it to compile, then copy, then compress.Ant doesn’t have a lifecycle. You have to define goals and goal dependencies. You have to attach a sequence of tasks to each goal manually.

  Ant没有正式的约定，例如通用的项目目录结构或默认行为。 您必须准确告诉Ant在哪里可以找到源以及在哪里放置输出。 非正式约定已逐渐形成，但尚未将其编入产品中。Ant是程序性的。 您必须确切地告诉Ant该做什么以及何时进行。 您必须告诉它进行编译，然后复制，然后进行压缩。Ant没有生命周期。 您必须定义目标和目标依赖性。 您必须手动将一系列任务附加到每个目标。

• Apache Maven
  Maven has conventions. It knows where your source code is because you followed the convention. Maven’s Compiler plugin put the bytecode in target/classes, and it produces a JAR file in target. Maven 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. Maven has a lifecycle which was invoked when you executed mvn install. This command told Maven to execute a series of sequential lifecycle phases until it reached the install lifecycle phase. 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.

  Maven有约定。 它知道您的源代码在哪里，因为您遵循了约定。 Maven的Compiler插件将字节码放入 target/classes中，并在target中生成JAR文件。Maven是声明性的。 您所要做的就是创建一个pom.xml文件，并将您的源代码放在默认目录中。 Maven负责其余的工作。Maven有一个生命周期，当您执行mvn install时会调用它。 该命令告诉Maven执行一系列顺序的生命周期阶段，直到到达安装生命周期阶段。 作为整个生命周期过程的副作用，Maven执行了许多默认插件目标，这些目标做了诸如编译和创建JAR之类的事情。

Maven has built-in intelligence about common project tasks in the form of Maven plugins. If you wanted to write and execute unit tests, all you would need to do is write the tests, place them in ${basedir}/src/test/java, add a test-scoped dependency on either TestNG or JUnit, and run mvn test. If you wanted to deploy a web application and not a JAR, all you would need to do is change your project type to war and put your docroot in ${basedir}/src/main/webapp. Sure, you can do all of this with Ant, but you will be writing the instructions from scratch. In Ant, you would first have to figure out where the JUnit JAR file should be. Then you would have to create a classpath that includes the JUnit JAR file. Then you would tell Ant where it should look for test source code, write a goal that compiles the test source to bytecode, and execute the unit tests with JUnit.

Maven以Maven插件的形式内置了有关常见项目任务的智能。 如果要编写和执行单元测试，则只需编写测试，将其放在$ {basedir} / src / test / java中，在TestNG或JUnit上添加测试范围的依赖项，然后运行mvn 测试。 如果要部署Web应用程序而不是JAR，只需将项目类型更改为war并将docroot放在$ {basedir} / src / main / webapp中。 当然，您可以使用Ant来完成所有这些操作，但是您将从头开始编写说明。 在Ant中，首先必须弄清楚JUnit JAR文件应该在哪里。 然后，您将不得不创建一个包含JUnit JAR文件的类路径。 然后，您将告诉Ant在哪里寻找测试源代码，编写一个将测试源编译为字节码的目标，并使用JUnit执行单元测试。

Without supporting technologies like antlibs and Ivy (and even with these supporting technologies), Ant has the feeling of a custom procedural build. An efficient set of Maven POMs in a project which adheres to Maven’s assumed conventions has surprisingly little XML compared to the Ant alternative. Another benefit of Maven is the reliance on widely-shared Maven plugins. Everyone uses the Maven Surefire plugin for unit testing, and if someone adds support for a new unit testing framework, you can gain new capabilities in your own build by just incrementing the version of a particular Maven plugin in your project’s POM.

在没有支持antlib和Ivy之类的技术（甚至没有这些支持技术）的情况下，Ant仍具有自定义程序构建的感觉。 与Ant替代方案相比，在符合Maven假定约定的项目中，一组有效的Maven POM具有很少的XML。 Maven的另一个好处是依赖广泛共享的Maven插件。 每个人都使用Maven Surefire插件进行单元测试，如果有人增加了对新单元测试框架的支持，则只需增加项目POM中特定Maven插件的版本，即可在自己的版本中获得新功能。

The decision to use Maven or Ant isn’t a binary one, and Ant still has a place in a complex build. If your current build contains some highly customized process, or if you’ve written some Ant scripts to complete a specific process in a specific way that cannot be adapted to the Maven standards, you can still use these scripts with Maven. Ant is made available as a core Maven plugin. Custom Maven plugins can be implemented in Ant, and Maven projects can be configured to execute Ant scripts within the Maven project lifecycle.

使用Maven或Ant的决定不是二选一的，而Ant在复杂的版本中仍然占有一席之地。 如果您当前的版本包含一些高度自定义的过程，或者您编写了一些Ant脚本以无法适应Maven标准的特定方式完成特定过程，则仍然可以将这些脚本与Maven一起使用。 Ant可作为核心Maven插件使用。 可以在Ant中实现自定义Maven插件，并且可以将Maven项目配置为在Maven项目生命周期内执行Ant脚本。