你是否早已厌倦了日复一日的手工构建工作，你是否对各个项目风格迥异的构建系统感到恐惧？Maven这个Java社区事实标准的项目管理工具，能帮你从琐碎的手工劳动中解脱出来，帮你规范整个组织的构建系统。不仅如此，它还有依赖管理、自动生成项目站点等超酷的特性。已经有无数的开源项目使用它来构建项目，促进团队交流。每天都由数以万计的开发者在访问中央仓库以获取他们需要的依赖。《Maven实战》告诉你Maven的本质是什么，深入阐述Maven的依赖管理、仓库、生命周期、插件等核心概念。你还能看到实际的案例演变，以及诸如多模块组织、建立Nexus私服、使用Hudson进行持续集成等企业开发的最佳实践。随着近两年Maven在国内的普及，越来越多的公司与项目开始接受并使用其作为 项目构建与 依赖管理工具，Java开发人员对Maven相关的资料的需求也越来越迫切。Maven在2007年至2010年取得了飞速的发展，现在几乎已经成为了所有Java开源项目的标配，Struts、Hibernate、 Ehcache等知名的开源项目都使用Maven进行管理。

Maven 3.0新功能和新特性

Maven 2.x与Maven 3.x的对比

Maven的价值
Maven的主要学习内容
基本内容：坐标和依赖、Maven仓库、生命周期和插件、聚合与继承等Maven的核心概念
括坐标、依赖、仓库、生命周期、插件、继承和多模块聚合

选择性内容：使用 Nexus建立私服（Maven仓库管理器Nexus）、使用Maven进行测试、使用Hudson进行持续集成、使用Maven构建Web应用、Maven的版本管理、Maven的灵活构 建、生成项目站点和Maven的m2eclipse插件等实用性较强的高级知识

一些相对高级且离散的知识点，包括测试、持续集成与Hudson、Web项目与自动化部署、自动化版本管理、智能适应环境差异的灵活构建、站点生成，以及Maven的Eclipse插件m2eclipse，

扩展级内容：Maven和 Archetype插件

Maven的安装、配置和基本使用方法

一些笔记：

何为Maven

Maven这个词可以翻译为“知识的积累”，也可以翻译为“专家”或“内行”。本书将 介绍Maven这一跨平台的项目管理工具。作为Apache组织中的一个颇为成功的开源项目，Maven主要服务于基于Java平台的项目构建、依赖管理 和项目信息管理。无论是小型的开源类库项目，还是大型的企业级应用；无论是传统的瀑布式开发，还是流行的敏捷模式，Maven都能大显身手。

何为构建

不管你是否意识到，构建（build）是每一位程序员每天都在做的工作。早上来 到公司，我们做的第一件事情就是从源码库签出最新的源码，然后进行单元测试，如果发现失败的测试，会找相关的同事一起调试，修复错误代码。接着回到自己的 工作上来，编写自己的单元测试及产品代码，我们会感激IDE随时报出的编译错误提示。

忙到午饭时间，代码编写得差不多了，测试也通过了，开心地享 用午餐，然后休息。下午先在昏昏沉沉中开了个例会，会议结束后喝杯咖啡继续工作。刚才在会上经理要求看测试报告，于是找了相关工具集成进IDE，生成了像 模像样的测试覆盖率报告，接着发了一封电子邮件给经理，松了口气。谁料QA小组又发过来了几个bug，没办法，先本地重现再说，于是熟练地用IDE生成了 一个WAR包，部署到Web容器下，启动容器。看到熟悉的界面了，遵循bug报告，一步步重现了bug……快下班的时候，bug修好了，提交代码，通知 QA小组，在愉快中结束了一天的工作。

仔细总结一下，我们会发现，除了编写源代码，我们每天有相当一部分时间花在了编 译、运行单元测试、生成文档、打包和部署等烦琐且不起眼的工作上，这就是构建。如果我们现在还手工这样做，那成本也太高了，于是有人用软件的方法让这一系 列工作完全自动化，使得软件的构建可以像全自动流水线一样，只需要一条简单的命令，所有烦琐的步骤都能够自动完成，很快就能得到最终结果。

Maven是优秀的构建工具

前面介绍了Maven的用途之一是服务于构建，它是一个异常强大的构建工具，能 够帮我们自动化构建过程，从清理、编译、测试到生成报告，再到打包和部署。我们不需要也不应该一遍又一遍地输入命令，一次又一次地点击鼠标，我们要做的是 使用Maven配置好项目，然后输入简单的命令(如mvn clean install)，Maven会帮我们处理那些烦琐的任务。

Maven是跨平台的，这意味着无论是在Windows上，还是在Linux或者Mac上，都可以使用同样的命令。

我们一直在不停地寻找避免重复的方法。设计的重复、编码的重复、文档的重复，当 然还有构建的重复。Maven最大化地消除了构建的重复，抽象了构建生命周期，并且为绝大部分的构建任务提供了已实现的插件，我们不再需要定义过程，甚至 不需要再去实现这些过程中的一些任务。最简单的例子是测试，我们没必要告诉Maven去测试，更不需要告诉Maven如何运行测试，只需要遵循Maven 的约定编写好测试用例，当我们运行构建的时候，这些测试便会自动运行。

想象一下，Maven抽象了一个完整的构建生命周期模型，这个模型吸取了大量其 他的构建脚本和构建工具的优点，总结了大量项目的实际需求。如果遵循这个模型，可以避免很多不必要的错误，可以直接使用大量成熟的Maven插件来完成我 们的任务（很多时候我们可能都不知道自己在使用Maven插件）。此外，如果有非常特殊的需求，我们也可以轻松实现自己的插件。

Maven还有一个优点，它能帮助我们标准化构建过程。在Maven之前，十个项目可能有十种构建方式；有了Maven之后，所有项目的构建命令都是简单一致的，这极大地避免了不必要的学习成本，而且有利于促进项目团队的标准化。

综上所述，Maven作为一个构建工具，不仅能帮我们自动化构建，还能够抽象构建过程，提供构建任务实现；它跨平台，对外提供了一致的操作接口，这一切足以使它成为优秀的、流行的构建工具。

Maven不是Java领域唯一的构建管理的解决方案。其他构建解决方案，如IDE、Make和Ant，并将它们与Maven进行比较。

IDE不是万能的

当然，我们无法否认优秀的IDE能大大提高开发效率。当前主流的IDE如Eclipse和NetBeans等都提供了强大的文本编辑、调试甚至重构功能。虽然使用简单的文本编辑器和命令行也能完成绝大部分开发工作，但很少有人愿意那样做。然而，IDE是有其天生缺陷的：

• IDE依赖大量的手工操作。编译、测试、代码生成等工作都是相互独立的，很难一键完成所有工作。手工劳动往往意味着低效，意味着容易出错。
• 很难在项目中统一所有的IDE配置，每个人都有自己的喜好。也正是由于这个原因，一个在机器A上可以成功运行的任务，到了机器B的IDE中可能就会失败。

我们应该合理利用IDE，而不是过多地依赖它。对于构建这样的任务，在IDE中一次次地点击鼠标是愚蠢的行为。Maven是这方面的专家，而且主流IDE都集成了Maven，我们可以在IDE中方便地运行Maven执行构建。

Make

Make也许是最早的构建工具，它由Stuart Feldman于1977年在Bell实验室创建。Stuart Feldman也因此于2003年获得了ACM国际计算机组织颁发的软件系统奖。目前Make有很多衍生实现，包括最流行的GNU Make和BSD Make，还有Windows平台的Microsoft nmake等。 Make由一个名为Makefile的脚本文件驱动，该文件使用Make自己定义的语法格式。其基本组成部分为一系列规则（Rules），而每一条规则又包括目标（Target）、依赖Prerequisite）和命令（Command）。 Make通过一系列目标和依赖将整个构建过程串联起来，同时利用本地命令完成每个目标的实际行为。Make的强大之处在于它可以利用所有系统的本地命令，尤其是UNIX/Linux系统，丰富的功能、强大的命令能够帮助Make快速高效地完成任务。 但是，Make将自己和操作系统绑定在一起了。也就是说，使用Make，就不能实现（至少很难）跨平台的构建，这对于Java来说是非常不友好的。此外，Makefile的语法也成问题，很多人抱怨Make构建失败的原因往往是一个难以发现的空格或Tab使用错误。

Ant

Ant不是指蚂蚁，而是意指“另一个整洁的工具”（Another Neat Tool），它最早用来构建著名的Tomcat，其作者James Duncan Davidson创作它的动机就是因为受不了Makefile的语法格式。我们可以将Ant看成是一个Java版本的Make，也正因为使用了Java，Ant是跨平台的。此外，Ant使用XML定义构建脚本，相对于Makefile来说，这也更加友好。

与Make类似，Ant有一个构建脚本build.xml，如下所示：

<?xml version="1.0"?>

<project name="Hello" default="compile">

<target name="compile" description="compile the Java source code to class files">

<mkdir dir="classes"/>

<javac srcdir="." destdir="classes"/>

</target>

<target name="jar" depends="compile" description="create a Jar file ">

<jar destfile="hello.jar">

<fileset dir="classes" includes="**/*.class"/>

<manifest>

<attribute name="Main.Class" value="HelloProgram"/>

</manifest>

</jar>

</target>

</project>

build.xml的基本结构也是目标（target）、依赖（depends），以及实现目标的任务。比如在上面的脚本中，jar目标用来创建应用程序jar文件，该目标依赖于compile目标，后者执行的任务是创建一个名为classes的文件夹，编译当前目录的java文件至classes目录。compile目标完成后，jar目标再执行自己的任务。Ant有大量内置的用Java实现的任务，这保证了其跨平台的特质，同时，Ant也有特殊的任务exec来执行本地命令。

和Make一样，Ant也都是过程式的，开发者显式地指定每一个目标，以及完成该目标所需要执行的任务。针对每一个项目，开发者都需要重新编写这一过程，这里其实隐含着很大的重复。Maven是声明式的，项目构建过程和过程各个阶段所需的工作都由插件实现，并且大部分插件都是现成的，开发者只需要声明项目的基本元素，Maven就执行内置的、完整的构建过程。这在很大程度上消除了重复。

Ant是没有依赖管理的，所以很长一段时间Ant用户都不得不手工管理依赖，这是一个令人头疼的问题。幸运的是，Ant用户现在可以借助Ivy管理依赖。而对于Maven用户来说，依赖管理是理所当然的，Maven不仅内置了依赖管理，更有一个可能拥有全世界最多Java开源软件包的中央仓库，Maven用户无须进行任何配置就可以直接享用。

不重复发明轮子

小张是一家小型民营软件公司的程序员，他所在的公司要开发一个新的Web项目。经过协商，决定使用Spring、iBatis和Tapstry。jar包去哪里找呢？公司里估计没有人能把Spring、iBatis和Tapstry所使用的jar包一个不少地找出来。大家的做法是，先到Spring的站点上去找一个spring.with.dependencies，然后去iBatis的网站上把所有列出来的jar包下载下来，对Tapstry、Apache commons等执行同样的操作。项目还没有开始，WEB.INF/lib下已经有近百个jar包了，带版本号的、不带版本号的、有用的、没用的、相冲突的，怎一个“乱”字了得！

在项目开发过程中，小张不时地发现版本错误和版本冲突问题，他只能硬着头皮逐一解决。项目开发到一半，经理发现最终部署的应用的体积实在太大了，要求小张去掉一些没用的jar包，于是小张只能加班加点地一个个删……

小张隐隐地觉得这些依赖需要一个框架或者系统来进行管理。

小张喜欢学习流行的技术，前几年Ant十分流行，他学了，并成为了公司这方面的专家。小张知道，Ant打包，无非就是创建目录，复制文件，编译源代码，使用一堆任务，如copydir、fileset、classpath、ref、target，然后再jar、zip、war，打包就成功了。

项目经理发话了：“兄弟们，新项目来了，小张，你来写Ant脚本！”

“是，保证完成任务！”接着，小张继续创建一个新的XML文件。target clean; target compile; target jar; …… 不知道他是否想过，在他写的这么多的Ant脚本中，有多少是重复劳动，有多少代码会在一个又一个项目中重现。既然都差不多，有些甚至完全相同，为什么每次都要重新编写？

终于有一天，小张意识到了这个问题，想复用Ant脚本，于是在开会时他说：“以后就都用我这个规范的Ant脚本吧，新的项目只要遵循我定义的目录结构就可以了。”经理听后觉得很有道理：“嗯，确实是个进步。”

这时新来的研究生发言了：“经理，用Maven吧，这个在开源社区很流行，比Ant更方便。”小张一听很惊讶，Maven真比自己的“规范化Ant”强大？其实他不知道自己只是在重新发明轮子，Maven已经有一大把现成的插件，全世界都在用，你自己不用写任何代码！

为什么没有人说“我自己写的代码最灵活，所以我不用Spring，我自己实现IoC；我不用Hibernate，我自己封装JDBC”？

Maven与极限编程
极限编程（XP）是近些年在软件行业红得发紫的敏捷开发方法，它强调拥抱变化。该软件开发方法的创始人Kent Beck提出了XP所追求的价值、实施原则和推荐实践。下面看一下Maven是如何适应XP的。

首先看一下Maven如何帮助XP团队实现一些核心价值：

• 简单。Maven暴露了一组一致、简洁的操作接口，能帮助团队成员从原来的高度自定义的、复杂的构建系统中解脱出来，使用Maven现有的成熟的、稳定的组件也能简化构建系统的复杂度。
• 交流与反馈。与版本控制系统结合后，所有人都能执行最新的构建并快速得到反馈。此外，自动生成的项目报告也能帮助成员了解项目的状态，促进团队的交流。

此外，Maven更能无缝地支持或者融入到一些主要的XP实践中：

• 测试驱动开发（TDD）。TDD强调测试先行，所有产品都应该由测试用例覆盖。而测试是Maven生命周期的最重要的组成部分之一，并且Maven有现成的成熟插件支持业界流行的测试框架，如JUnit和TestNG。
• 十分钟构建。十分钟构建强调我们能够随时快速地从源码构建出最终的产品。这正是Maven所擅长的，只需要一些配置，之后用一条简单的命令就能让Maven帮你清理、编译、测试、打包、部署，然后得到最终的产品。
• 持续集成（CI）。CI强调项目以很短的周期（如15分钟）集成最新的代码。 实际上,CI的前提是源码管理系统和构建系统。目前业界流行的CI服务器如Hudson和CruiseControl都能很好地和Maven进行集成。也 就是说，使用Maven后，持续集成会变得更加方便。
• 富有信息的工作区。 这条实践强调开发者能够快速方便地了解到项目的最新状态。当然，Maven并不会帮你把测试覆盖率报告贴到墙上，也不会在你的工作台上放个鸭子告诉你构建 失败了。不过使用Maven发布的项目报告站点，并配置你需要的项目报告，如测试覆盖率报告，都能帮你把信息推送到开发者眼前。

上述这些实践并非只在XP中适用。事实上，除了其他敏捷开发方法如SCRUM之外，几乎任何软件开发方法都能借鉴这些实践。也就是说，Maven几乎能够很好地支持任何软件开发方法。
例 如，在传统的瀑布模型开发中，项目依次要经历需求开发、分析、设计、编码、测试和集成发布阶段。从设计和编码阶段开始，就可以使用Maven来建立项目的 构建系统。在设计阶段，也完全可以针对设计开发测试用例，然后再编写代码来满足这些测试用例。然而，有了自动化构建系统，我们可以节省很多手动的测试时 间。此外，尽早地使用构建系统集成团队的代码，对项目也是百利而无一害。最后，Maven还能帮助我们快速地发布项目。
Maven不仅仅是构建工具
Java不仅是一门编程语言，还是一个平台，通过JRuby和Jython，我 们可以在Java平台上编写和运行Ruby和Python程序。我们也应该认识到，Maven不仅是构建工具，还是一个依赖管理工具和项目信息管理工具。 它提供了中央仓库，能帮我们自动下载构件。

在这个开源的年代里，几乎任何Java应用都会借用一些第三方的开源类库，这些 类库都可通过依赖的方式引入到项目中来。随着依赖的增多，版本不一致、版本冲突、依赖臃肿等问题都会接踵而来。手工解决这些问题是十分枯燥的，幸运的是 Maven提供了一个优秀的解决方案，它通过一个坐标系统准确地定位每一个构件（artifact），也就是通过一组坐标Maven能够找到任何一个 Java类库（如jar文件）。Maven给这个类库世界引入了经纬，让它们变得有秩序，于是我们可以借助它来有序地管理依赖，轻松地解决那些繁杂的依赖 问题。

Maven还能帮助我们管理原本分散在项目中各个角落的项目信息，包括项目描 述、开发者列表、版本控制系统地址、许可证、缺陷管理系统地址等。这些微小的变化看起来很琐碎，并不起眼，但却在不知不觉中为我们节省了大量寻找信息的时 间。除了直接的项目信息，通过Maven自动生成的站点，以及一些已有的插件，我们还能够轻松获得项目文档、测试报告、静态分析报告、源码版本日志报告等 非常具有价值的项目信息。

Maven还为全世界的Java开发者提供了一个免费的中央仓库，在其中几乎可以找到任何的流行开源类库。通过一些Maven的衍生工具（如Nexus），我们还能对其进行快速地搜索。只要定位了坐标，Maven就能够帮我们自动下载，省去了手工劳动。

使用Maven还能享受一个额外的好处，即Maven对于项目目录结构、测试用 例命名方式等内容都有既定的规则，只要遵循了这些成熟的规则，用户在项目间切换的时候就免去了额外的学习成本，可以说是约定优于配置 （Convention Over Configuration）。

附《Maven实战》目录
第1章maven简介/1
1.1何为maven/2
1.1.1何为构建/2
1.1.2maven是优秀的构建工具/2
1.1.3maven不仅仅是构建工具/3
1.2为什么需要maven/4
1.2.1组装pc和品牌pc/4
1.2.2ide不是万能的/4
1.2.3make/5
1.2.4ant/5
1.2.5不重复发明轮子/6
1.3maven与极限编程/7
1.4被误解的maven/8
1.5小结/9
第2章maven的安装和配置/10
2.1在windows上安装maven/11
2.1.1检查jdk安装/11
2.1.2下载maven/11
.2.1.3本地安装/12
2.1.4升级maven/13
2.2在基于unix的系统上安装maven/13
2.2.1下载和安装/13
2.2.2升级maven/15
2.3安装目录分析/15
2.3.1m2_home/15
2.3.2~/m2/16
2.4设置http代理/17
2.5安装m2eclipse/18
2.6安装netbeans maven插件/22
2.7maven安装最佳实践/24
2.7.1设置maven_opts环境变量/24
2.7.2配置用户范围settingsxml/24
2.7.3不要使用ide内嵌的maven/25
2.8小结/26
第3章maven使用入门/27
3.1编写pom/28
3.2编写主代码/29
3.3编写测试代码/30
3.4打包和运行/34
3.5使用archetype生成项目骨架/36
3.6m2eclipse简单使用/37
3.6.1导入maven项目/37
3.6.2创建maven项目/39
3.6.3运行mvn命令/39
3.7netbeans maven插件简单使用/41
3.7.1打开maven项目/41
3.7.2创建maven项目/42
3.7.3运行mvn命令/43
3.8小结/44
第4章背景案例/45
4.1简单的账户注册服务/46
4.2需求阐述/46
4.2.1需求用例/46
4.2.2界面原型/484.3简要设计/49
4.3.1接口/49
4.3.2模块结构/49
4.4小结/50
第5章坐标和依赖/51
5.1何为maven坐标/52
5.2坐标详解/53
5.3accountemail/54
5.3.1accountemail 的pom/54
5.3.2accountemail的主代码/56
5.3.3accountemail的测试代码/60
5.3.4构建accountemail/62
5.4依赖的配置/62
5.5依赖范围/63
5.6传递性依赖/64
5.6.1何为传递性依赖/64
5.6.2传递性依赖和依赖范围/65
5.7依赖调解/66
5.8可选依赖/66
5.9最佳实践/68
5.9.1排除依赖/68
5.9.2归类依赖/69
5.9.3优化依赖/71
5.10小结/74
第6章仓库/75
6.1何为maven仓库/76
6.2仓库的布局/76
6.3仓库的分类/78
6.3.1本地仓库/79
6.3.2远程仓库/80
6.3.3中央仓库/80
6.3.4私服/81
6.4远程仓库的配置/82
6.4.1远程仓库的认证/83
6.4.2部署至远程仓库/84
6.5快照版本/85
6.6从仓库解析依赖的机制/87
6.7镜像/89
6.8仓库搜索服务/90
6.8.1sonatype nexus/90
6.8.2jarvana/91
6.8.3mvnbrowser/91
6.8.4mvnrepository/92
6.8.5选择合适的仓库搜索服务/93
6.9小结/93
第7章生命周期和插件/94
7.1何为生命周期/95
7.2生命周期详解/96
7.2.1三套生命周期/97
7.2.2clean生命周期/97
7.2.3default生命周期/97
7.2.4site生命周期/98
7.2.5命令行与生命周期/98
7.3插件目标/997.4插件绑定/99
7.4.1内置绑定/100
7.4.2自定义绑定/102
7.5插件配置/104
7.5.1命令行插件配置/104
7.5.2pom中插件全局配置/104
7.5.3pom中插件任务配置/105
7.6获取插件信息/106
7.6.1在线插件信息/106
7.6.2使用mavenhelpplugin描述插件/108
7.7从命令行调用插件/109
7.8插件解析机制/110
7.8.1插件仓库/110
7.8.2插件的默认groupid/111
7.8.3解析插件版本/111
7.8.4解析插件前缀/112
7.9小结/114
第8章聚合与继承/115
8.1accountpersist/116
8.1.1accountpersist的pom/116
8.1.2accountpersist的主代码/118
8.1.3accountpersist的测试代码/123
8.2聚合/124
8.3继承/127
8.3.1accountparent/127
8.3.2可继承的pom元素/130
8.3.3依赖管理/131
8.3.4插件管理/135
8.4聚合与继承的关系/137
8.5约定优于配置/139
8.6反应堆/143
8.6.1反应堆的构建顺序/144
8.6.2裁剪反应堆/145
8.7小结/147
第9章使用nexus创建私服/148
9.1nexus简介/149
9.2安装nexus/149
9.2.1下载nexus/149
9.2.2bundle方式安装nexus/150
9.2.3war方式安装nexus/151
9.2.4登录nexus/152
9.3nexus的仓库与仓库组/152
9.3.1nexus内置的仓库/152
9.3.2nexus仓库分类的概念/154
9.3.3创建nexus宿主仓库/154
9.3.4创建nexus代理仓库/155
9.3.5创建nexus仓库组/156
9.4nexus的索引与构件搜索/157
9.5配置maven从nexus下载构件/160
9.6部署构件至nexus/163
9.6.1使用maven部署构件至nexus/163
9.6.2手动部署第三方构件至nexus/164
9.7nexus的权限管理/165
9.7.1nexus的访问控制模型/165
9.7.2为项目分配独立的仓库/167
9.8nexus的调度任务/169
9.9其他私服软件/170
9.10小结/171
第10章使用maven进行测试/172
10.1accountcaptcha/173
10.1.1accountcaptcha的pom/173
10.1.2accountcaptcha的主代码/175
10.1.3accountcaptcha的测试代码/180
10.2mavensurefireplugin简介/184
10.3跳过测试/184
10.4动态指定要运行的测试用例/186
10.5包含与排除测试用例/187
10.6测试报告/188
10.6.1基本的测试报告/189
10.6.2测试覆盖率报告/190
10.7运行testng测试/191
10.8重用测试代码/193
10.9小结/194
第11章使用hudson进行持续集成/195
11.1持续集成的作用、过程和优势/196
11.2hudson简介/198
11.3安装hudson/199
11.4准备subversion仓库/200
11.5hudson的基本系统设置/203
11.6创建hudson任务/205
11.6.1hudson任务的基本配置/205
11.6.2hudson任务的源码仓库配置/206
11.6.3hudson任务的构建触发配置/207
11.6.4hudson任务的构建配置/208
11.7监视hudson任务状态/209
11.7.1全局任务状态/209
11.7.2自定义任务视图/211
11.7.3单个任务状态/212
11.7.4maven项目测试报告/214
11.8hudson用户管理/215
11.9邮件反馈/217
11.10hudson工作目录/218
11.11小结/220
第12章使用maven构建web应用/221
12.1web项目的目录结构/222
12.2accountservice/224
12.2.1accountservice的pom/224
12.2.2accountservice的主代码/225
12.3accountweb/230
12.3.1accountweb的pom/230
12.3.2accountweb的主代码/231
12.4使用jettymavenplugin进行测试/237
12.5使用cargo实现自动化部署/239
12.5.1部署至本地web容器/239
12.5.2部署至远程web容器/241
12.6小结/242
第13章版本管理/243
13.1何为版本管理/244
13.2maven的版本号定义约定/245
13.3主干、标签与分支/246
13.4自动化版本发布/247
13.5自动化创建分支/252
13.6gpg签名/253
13.6.1gpg及其基本使用/254
13.6.2maven gpg plugin/255
13.7小结/258
第14章灵活的构建/259
14.1maven属性/260
14.2构建环境的差异/262
14.3资源过滤/263
14.4maven profile/265
14.4.1针对不同环境的profile/265
14.4.2激活profile/266
14.4.3profile的种类/269
14.5web资源过滤/271
14.6在profile中激活集成测试/272
14.7小结/274
第15章生成项目站点/275
15.1最简单的站点/276
15.2丰富项目信息/278
15.3项目报告插件/281
15.3.1javadocs/281
15.3.2source xref/283
15.3.3checkstyle/284
15.3.4pmd/286
15.3.5changelog/288
15.3.6cobertura/289
15.4自定义站点外观/290
15.4.1站点描述符/290
15.4.2头部内容及外观/291
15.4.3皮肤/292
15.4.4导航边栏/294
15.5创建自定义页面/295
15.6国际化/298
15.7部署站点/299
15.8小结/302
第16章m2eclipse/303
16.1m2eclipse简介/304
16.2新建maven项目/304
16.3导入maven项目/306
16.3.1导入本地maven项目/307
16.3.2从scm仓库导入maven项目/308
16.3.3m2eclipse中maven项目的结构/309
16.4执行mvn命令/310
16.5访问maven仓库/312
16.5.1maven仓库视图/312
16.5.2搜索构件和java类/314
16.6管理项目依赖/315
16.6.1添加依赖/315
16.6.2分析依赖/317
16.7其他实用功能/319
16.7.1pom编辑的代码提示/319
16.7.2effective pom/320
16.7.3下载依赖源码/321
16.8小结/321
第17章编写maven插件/323
17.1编写maven插件的一般步骤/324
17.2案例：编写一个用于代码行统计的maven插件/324
17.3mojo标注/331
17.4mojo参数/332
17.5错误处理和日志/336
17.6测试maven插件/337
17.7小结/341
第18章archetype/342
18.1archetype使用再叙/343
18.1.1maven archetype plugin/343
18.1.2使用archetype的一般步骤/343
18.1.3批处理方式使用archetype/344
18.1.4常用archetype介绍/345
18.2编写archetype/347
18.3archetype catalog/352
18.3.1什么是archetype catalog/352
18.3.2archetype catalog的来源/353
18.3.3生成本地仓库的archetype catalog/354
18.3.4使用nexusarchetypeplugin/355
18.4小结/356
附录apom元素参考/357
附录bsettings元素参考/359
附录c常用插件列表/360

Apache Maven 3.x

Maven is a project development management and comprehension tool. Based on the concept of a project object model: builds, dependency management, documentation creation, site publication, and distribution publication are all controlled from the declarative file. Maven can be extended by plugins to utilise a number of other development tools for reporting or the build process.