The conventional view serves to protect us from the painful job of thinking.
传统观点的作用就在于使我们免受思考的痛苦。
———John Kenneth Galbraith
本章重点
介绍 Maven
Maven的依赖管理
Maven的Surefire插件
Maven Surefire Report插件
在本章中，我们将讨论和揭示另一种叫做 Maven的常用构建系统工具。我们将向你展示 Maven是如何不同于Ant的，同时也简单地介绍了Maven这个构建系统。如果你刚开始接触 Maven或者你需要通过一种方法来持续地启动测试,那么这一部分内容将对你非常有用。
人们有时提到Maven，认为它就是类似于Ant的一种工具。一旦他们发现 Maven完全不同于Ant，他们又会觉得很有挫败感。不要担心，不只是你一个人有这种体会。这就是为什么我们要花费本章开头几页的篇幅来解释对于理解 Maven最必不可少的内容:Maven是如何不同于Ant 的。然后，我们给出了一些真实场景中的示例，包括编译测试用例、运行测试用例以及生成完美的报告。
在本章的最后,你将掌握如何在你的计算机上搭建环境,从而使用Maven来构建不同的Java项目，包括管理它们的依赖库、执行JUnit测试以及生成JUnit 报告。
一旦你在几个项目上使用了 Ant，你就会注意到几乎所有（或者占相当大的比例)的项目都需要同一个Ant脚本。虽然这些脚本通过剪切和粘贴非常容易重复使用，但是每一个新的项目都会需要一些修改，才能使得Ant构建文件可以正确地工作。此外,每个项目通常都包含几个子项目，每个子项目都需要你创建和维护一个 Ant构建文件。Maven (http://maven.apache.org/）则在Ant停下的地方继续前进，这使得它自然而然地适用于许多团队。像Ant一样，Maven是一个运行其他工具的工具,但是 Maven旨在把工具的复用带到了一个新的水平。如果Ant是一个源代码构建框架,那么Maven 就是一个源代码构建环境。
为了更好地理解 Maven是如何工作的，你需要理解Maven背后的关键点(即关键原理)。Maven被设计用来将构建系统提升到一个新的水平,超越了Ant。所以你需要了解 Maven社群不喜欢Ant中的某些事情,以及它如何试图在设计 Maven时避免这些事情。也就说，你需要熟悉将Maven作为一个全新项目启动的核心原因。
自Maven项目开始,为了项目的整个软件架构,就已经明确了某些基本原则。这些原则的作用是简化使用 Maven 的开发，并且使得开发人员能够更加容易地实现构建系统。Maven基本的理念之一就是构建系统应该尽可能得简单——软件工程师不应该在实现构建系统上花费大量的时间。从头开始启动一个新项目应该非常简单,然后迅速开始开发软件,而不是将宝贵的时间浪费在设计和实现构建系统上。
在本节中,我们详细地描述了Maven的每一条核心原则,同时我们从一名开发人员的角度解释了这些核心原则对我们意味着什么。
这个功能是一项软件设计原则，其目的是减少需要工程师进行配置的次数，同时有利于引人开发人员需要遵守的大量传统规则。作为一名开发人员,你可以以这种方式跳过每个项目都必需的冗长乏味的配置过程,并且能够使自己专注于工作中更重要的部分。
约定优于配置（Convention over configuration)是Maven项目最强大的原则之一。我们通过它的一个应用程序示例,来看一下构建过程的目录结构。当Maven项目被启动时,一些初级的Maven开发人员会注意到,对于每一个Ant构建文件来说，编写构建文件的用户必须设计目录结构:声明源代码目录、构建目录和许多构建本身所需要的其他目录。
虽然Ant社群试图说明一些目录名称和目录结构,但仍然没有关于目录应该被如何命名的官方规范（即约定)。例如，许多用户通过声明target.dir属性来表示保存编译类的目录,而其他用户可能习惯于使用 build.dir属性,并且看起来他们不太习惯使用target.dir。同样，许多人习惯将他们的源代码放置在 src/目录中，但另一些人习惯将源代码放置在src/java/目录中。Maven团队决定、他们应该为此提出一个约定，而不是允许软件工程师每次自己来选择构建结构。
这就产生了现在所谓的“Maven目录结构约定”。使用 Maven，所有你所需要的目录都已被定义好，而不再需要你自己定义。例如,Maven约定src/main/java/目录用来保存项目的Java代码，而src/main/test/目录用来保存项目的单元测试，目标就是构建目录,等等。并且不仅仅是不需要定义目录结构了,在后面的章节中,我们会讨论到插件本身,你将会看到每一个插件都已经被定义了一个默认状态，所以你就不需要再定义它了。
这听起来非常不错,但是我们不会因此失去一些项目的灵活性吗?如果我们想使用Maven，并且我们的源代码保存在另一个目录下,那么又会怎么样?在这一点上,Maven是很强大的。虽然它提供了约定，但是你仍然可以在任何时候重写该约定，并使用你选择的配置。
这是 Maven引入的第2个关键原则。在项目被启动的时候，对 Java项目来说,事实上的构建系统是Ant。使用 Ant，你就不得不为项目本身指定项目的依赖库。Maven引入了的中心仓库 (Central Repository)概念——一个在网络上用来存储各种工件（依赖库）的地点。Maven构建工具通过读取项目的构建描述文件、下载各种工件的必要版本来解析它们，然后将它们添加到应用程序的classpath中。这样，你唯一需要做的是在构建描述符的依赖库部分中列出所有的依赖库，如下所示：
然后你就可以在任何其他机器上任意地构建软件,没有必要再将依赖库与你的项目进行绑定,等等。
但是，Maven也引入了本地仓库的概念。这是在用户硬盘上的一个目录(在UNIX系统上是~1.m2/repository/，而在 Windows系统上是 C:\Documents and Settings\<User-Name > l.m2lrepositoryl)，Maven将它刚刚从中心仓库下载的各种工件保存在这个目录中。此外，在你构建了项目之后,你的工件会被安装在本地仓库中,便于以后被一些其他的项目所调用——简单又简洁。
