Maven实战
http://www.infoq.com/cn/maven-practice
Maven实战（一）——坐标规划
作者 许晓斌 发布于 2010年12月12日
坐标是什么？为什么要规划？
坐标是Maven最基本的概念，它就像每个构件的身份证号码，有了它我们就可以在数以千万计的构件中定位任何一个我们感兴趣的构件。举个最简单的例子，如果没有坐标，使用JUnit的时候，用户就需要去下载依赖jar包，用依赖的方式，简单配置使用如junit:junit:4.8.2就可以了。这里第一个junit是groupId，第二个junit是artifactId，4.8.2是version。
Maven的很多其他核心机制都依赖于坐标，其中最显著的就是仓库和依赖管理。对于仓库来说，有了坐标就知道在什么位置存储构件的内容，例如junit:junit:4.8.2就对应仓库中的路径/junit/junit/4.8.2/junit-4.8.2.pom和/junit/junit/4.8.2/junit-4.8.2.jar这样的文件，读者可以直接访问中央仓库地址看到这样的仓库布局，或者浏览本地仓库目录~/.m2/repository/以获得直观的体验。
依赖的配置也是完全基于坐标的，例如：
junit junit 4.8.2 test
有了正确的坐标,Maven才能够在正确的位置找到依赖文件并使用，这里值为test的scope是用来控制该依赖只在测试时可用，与坐标无关。
正因为坐标是Maven核心的核心，因此规划正确的坐标至关重要，如果你使用了模糊不清的坐标，那么你的用户就很难找到你的构件，或者即使找到了，也容易写错。错误的使用坐标，还会造成冲突，如果你也使用junit这样的groupId，那会发生什么？下面先看一些不是很规范的坐标使用方式。
坐标规划的原则
滥用坐标、错用坐标的样例比比皆是，在中央仓库中我们能看到SpringFramework有两种坐标，其一是直接使用springframework作为groupId，如springframework:spring-beans:1.2.6，另一种是用org.springframework作为groupId，如org.springframework:spring-beans:2.5。细心看看，前一种方式显得比较随意，后一种方式则是基于域名衍生出来的，显然后者更合理，因为用户能一眼根据域名联想到其Maven坐标，方便寻找。因此新版本的SpringFramework构件都使用org.springframework作为groupId。由这个例子我们可以看到坐标规划一个原则是基于项目域名衍生。其实很多流行的开源项目都破坏了这个原则，例如JUnit，这是因为Maven社区在最开始接受构件并部署到中央仓库的时候，没有很很严格的限制，而对于这些流行的项目来说，一时间更改坐标会影响大量用户，因此也算是个历史遗留问题了。
还有一个常见的问题是将groupId直接匹配到公司或者组织名称，因为乍一看这是显而易见的。例如组织是zoo.com，有个项目是dog，那有些人就直接使用groupId com.zoo了。如果项目只有一个模块，这是没有什么问题的，但现实世界的项目往往会有很多模块，Maven的一大长处就是通过多模块的方式管理项目。那dog项目可能会有很多模块，我们用坐标的哪个部分来定义模块呢？groupId显然不对，version也不可能是，那只有artifactId。因此要这里有了另外一个原则，用artifactId来定义模块，而不是定义项目。接下来，很显然的，项目就必须用groupId来定义。因此对于dog项目来说，应该使用groupId com.zoo.dog，不仅体现出这是zoo.com下的一个项目，而且可以与该组织下的其他项目如com.zoo.cat区分开来。
除此之外，artifactId的定义也有最佳实践，我们常常可以看到一个项目有很多的模块，例如api，dao，service，web等等。Maven项目在默认情况下生成的构件，其名称不会是基于artifactId，version和packaging生成的，例如api-1.0.jar，dao-1.0.jar等等，他们不会带有groupId的信息，这会造成一个问题，例如当我们把所有这些构件放到Web容器下的时候，你会发现项目dog有api-1.0.jar，项目cat也有api-1.0.jar，这就造成了冲突。更坏的情况是，dog项目有api-1.0.jar，cat项目有api-2.0.jar，其实两者没什么关系，可当放在一起的时候，却很容易让人混淆。为了让坐标更加清晰，又出现了一个原则，即在定义artiafctId时也加入项目的信息，例如dog项目的api模块，那就使用artifactId dog-api，其他就是dog-dao，dao-service等等。虽然连字号是不允许出现在Java的包名中的，但Maven没这个限制。现在dog-api-1.0.jar，cat-2.0.jar被放在一起时，就不容易混淆了。
关于坐标，我们还没谈到version，这里不再详述因为读者可以从Maven: The Complete Guide中找到详细的解释，简言之就是使用这样一个格式：
<主版本>.<次版本>.<增量版本>-<限定符>
其中主版本主要表示大型架构变更，次版本主要表示特性的增加，增量版本主要服务于bug修复，而限定符如alpha、beta等等是用来表示里程碑。当然不是每个项目的版本都要用到这些4个部分，根据需要选择性的使用即可。在此基础上Maven还引入了SNAPSHOT的概念，用来表示活动的开发状态，由于不涉及坐标规划，这里不进行详述。不过有点要提醒的是，由于SNAPSHOT的存在，自己显式地在version中使用时间戳字符串其实没有必要。
Classifier
Classifier可能是最容易被忽略的Maven特性，但它确实非常重要，我们也需要它来帮助规划坐标。设想这样一个情况，有一个jar项目，就说是 吧，运行它用户就能在命令行上画一只小狗出来。现在用户的要求是希望你能提供一个zip包，里面不仅包含这个可运行的jar，还得包含源代码和文档，换句话说，这是比较正式的分发包。这个文件名应该是怎样的呢？dog-cli-1.0.jar dog-cli-1.0.zip？不够清楚，仅仅从扩展名很难分辨什么是Maven默认生成的构件，什么是额外配置生成分发包。如果能是dog-cli-1.0-dist.zip就最好了。这里的dist就是classifier，默认Maven只生成一个构件，我们称之为主构件，那当我们希望Maven生成其他附属构件的时候，就能用上classifier。常见的classifier还有如dog-cli-1.0-sources.jar表示源码包，dog-cli-1.0-javadoc.jar表示JavaDoc包等等。制作classifier的方式多种多样，其中最重要的一种是使用Maven Assembly Plugin，感兴趣的读者可以进一步研究。
小结
本文是InfoQ Maven专栏的第一篇，讨论的是Maven坐标的规划，包括如何正确的使用groupId、artifactId、version，以及classfier。笔者在维护Maven中央仓库的工作过程中遇到过各种各样模糊的甚至是错误的坐标，它们的存在给广大Maven用户带来的极大的不便。本文抛出一些较好的实践，帮助大家更好的使用Maven。如果读者有相关的经验总结，也请不吝分享。
关于作者
许晓斌（Juven Xu），国内社区公认的Maven技术专家、Maven中文用户组创始人、Maven技术的先驱和积极推动者。对Maven有深刻的认识，实战经验丰富，不仅撰写了大量关于Maven的技术文章，而且还翻译了开源书籍《Maven权威指南》，对Maven技术在国内的普及和发展做出了很大的贡献。就职于Maven之父的公司，负责维护Maven中央仓库，是Maven仓库管理器Nexus（著名开源软件）的核心开发者之一，曾多次受邀到淘宝等大型企业开展Maven方面的培训。此外，他还是开源技术的积极倡导者和推动者，擅长Java开发和敏捷开发实践。他的个人网站是：http://www.juvenxu.com。
【编者按】InfoQ中文站有幸邀请到Sonotype（Maven背后的公司）在中国唯一的员工、《Maven实战》的作者许晓斌先生，在InfoQ中文站开辟Maven的专栏，为开发者带来一些Maven的高级话题，以及他积累多年的Maven经验分享。
Maven实战（二）——POM重构之增还是删
作者 许晓斌 发布于 2010年12月27日
重构是广大开发者再熟悉不过的技术，在Martin Fowler的《重构——改善既有代码的设计》一书中，其定义为“重构(名词):对软件内部结构的一种调整,目的是在不改变软件之可察行为前提下,提高其可理解性,降低其修改成本.”以及“重构(动词):使用一系列重构准则(手法),在不改变软件之可察行为前提下,调整其结构.”。重构能够改善软件设计，使代码更易读，更容易找出bug，并帮助你更快速地编码。较之于一般的代码来说，Maven的POM简单很多，不过随着项目的成长，模块的增多，POM的内容也会变多，这个时候，我们可以对POM进行重构，在保持构建成功的前提下，简化POM内容，使其更简洁易懂。
前提
大家都知道，如果没有单元测试为前提，对代码进行重构是非常危险的。同样，在重构POM之前，项目应该有足够的自动化测试保证POM重构不会破坏构建。例如，重构POM的时候可能会删除或添加依赖，造成依赖版本变化，依赖范围变化，插件版本变化等等，这些变化可能会导致项目编译失败，或者测试失败。在自动化测试及构建的基础上，最好能够有持续集成环境，以保证POM的修改可能造成的问题能够及时的被发现和修复。笔者目前工作的项目有一个对应的持续集成任务，该任务基于Hudson，每10分钟检查一次SCM，如果发现变更则构建项目，并反馈结果。这样，我就不用担心自己修改POM会引入潜在的问题。
增还是删
有时候这个答案是很显然的，当你的POM中存在一些依赖或者插件配置，但实际代码没有用到这些配置的时候，应该尽早删掉它们以免给人带来困惑。
还有一种常见的情况，我们可以删掉一些POM的元素，例如POM中配置了继承，当前模块与父模块使用同样的groupId和version时，就可以将
4.0.0 com.juvenxu.sample sample-parent 0.0.1-SNAPSHOT sample-foo jar ...
上述配置就sample-foo就没有groupId和version，需要注意的是，artifactId是不能被删除的，因为该元素不能也不应该被继承，父子模块应当使用不同的artifactId值。
除了删之外，有些时候我们还需要在POM中增加一些XML元素，目的是为了让POM更清晰易读，且保证Maven构建的稳定性。考虑如下的插件配置：
maven-compiler-plugin 1.5 1.5
虽然没有groupId及version，但这段配置是完全合法的。当插件没有groupId配置的时候，Maven会认为它是官方插件而自动使用org.apache.maven.plugins作为groupId，当插件没有version配置的时候，Maven则会使用最新的版本（Maven 2会使用最新的版本，包括SNAPSHOT，而Maven 3则只使用最新的非SNAPSHOT版本）。这段配置有两个问题，首先，如果让一个不熟悉Maven的开发者来看这段配置，他会感到费解，groupId和version究竟是什么呢？这与不清晰的代码是一个意思，有时候一些程序员为了让代码更短，会采用一些奇怪的语法和变量名，虽然代码量是少了，但沟通成本增加了，得不偿失。其次，让Maven猜测版本会有潜在的风险，因为插件的最新版本可能会变化，而这种变化对于Maven使用者来说通常是隐藏的，特别是在Maven 2中，甚至可能引入SNAPSHOT版本的插件，这是非常危险的。基于这两个原因，使用插件的时候，我们应当配置清楚groupId和version，如：
org.apache.maven.plugins maven-compiler-plugin 2.3.2 1.5 1.5
基于类似的原因，在配置项目依赖的时候，我们也应当一直显式地写明依赖版本，以避免Maven在不同的时刻引入不同版本的依赖而导致项目构建的不稳定。
除了上面提到的增删点之外，Maven官方还提供了一个非常有用的Maven Dependency Plugin来帮助我们分析项目中哪些依赖配置应该删除，那些依赖配置应该增加。Maven Dependency Plugin的analyze目标能够帮助分析项目依赖，例如运行命令 mvn dependency:analyze ，可以看到如下输出：
[INFO] --- maven-dependency-plugin:2.1:analyze (default-cli) @ sample-bar --- [WARNING] Used undeclared dependencies found: [WARNING] org.springframework:spring-context:jar:2.5.6:compile [WARNING] Unused declared dependencies found: [WARNING] org.springframework:spring-core:jar:2.5.6:compile [WARNING] org.springframework:spring-beans:jar:2.5.6:compile [INFO] ------------------------------------------------------------------------
这里的 Used undeclared dependencies 是指那些在项目中直接使用到的，但没有在POM中配置的依赖。例如该例中可能项目中的一些类有关于spring-context的Java import声明，但spring-context这个依赖实际是通过传递性依赖进入classpath的，这就意味者潜在的风险。一般来说我们对直接依赖的版本变化会比较清楚，因为那是我们自己直接配置的，但对于传递性依赖的版本变化，就会比较模糊，当这种变化造成构建失败的时候，就很难找到原因。因此我们应当增加这些 Used undeclared dependencies 。
依赖分析还提供了 Unused declared dependencies 供我们参考，这表示那些我们配置了，但并未直接使用的依赖。需要注意的时，对于这些依赖，我们不该直接简单地删除。由于dependency:analyze只分析编译主代码和测试代码使用的依赖，一些执行测试和运行时的依赖它发现不了，因此还需要人工分析。通常情况，Unused declared dependencies 还是能帮助我们发现一些无用的依赖配置。
最后，还一些重要的POM内容通常被大多数项目所忽略，这些内容不会影响项目的构建，但能方便信息的沟通，它们包括项目URL，开发者信息，SCM信息，持续集成服务器信息等等，这些信息对于开源项目来说尤其重要。对于那些想了解项目的人来说，这些信息能他们帮助找到想要的信息，基于这些信息生成的Maven站点也更有价值。相关的POM配置很简单，如：
... ... ... ... ... ... ... ... ...
小结
无论是对POM内容进行增还是删，其目的都是一样的，就是为了让POM更清晰易懂且让构建更稳定。从这点来说，POM重构与一般的代码重构是类似的。需要谨记的是，重构的前提是完善的自动化测试和持续集成。本文介绍的单个POM规模的重构，下篇文章笔者会介绍多模块项目的POM重构等内容。
关于作者
许晓斌（Juven Xu），国内社区公认的Maven技术专家、Maven中文用户组创始人、Maven技术的先驱和积极推动者。对Maven有深刻的认识，实战经验丰富，不仅撰写了大量关于Maven的技术文章，而且还翻译了开源书籍《Maven权威指南》，对Maven技术在国内的普及和发展做出了很大的贡献。就职于Maven之父的公司，负责维护Maven中央仓库，是Maven仓库管理器Nexus（著名开源软件）的核心开发者之一，曾多次受邀到淘宝等大型企业开展Maven方面的培训。此外，他还是开源技术的积极倡导者和推动者，擅长Java开发和敏捷开发实践。他的个人网站是：http://www.juvenxu.com。
Maven实战（二）——POM重构之增还是删
作者 许晓斌 发布于 2010年12月27日
重构是广大开发者再熟悉不过的技术，在Martin Fowler的《重构——改善既有代码的设计》一书中，其定义为“重构(名词):对软件内部结构的一种调整,目的是在不改变软件之可察行为前提下,提高其可理解性,降低其修改成本.”以及“重构(动词):使用一系列重构准则(手法),在不改变软件之可察行为前提下,调整其结构.”。重构能够改善软件设计，使代码更易读，更容易找出bug，并帮助你更快速地编码。较之于一般的代码来说，Maven的POM简单很多，不过随着项目的成长，模块的增多，POM的内容也会变多，这个时候，我们可以对POM进行重构，在保持构建成功的前提下，简化POM内容，使其更简洁易懂。
前提
大家都知道，如果没有单元测试为前提，对代码进行重构是非常危险的。同样，在重构POM之前，项目应该有足够的自动化测试保证POM重构不会破坏构建。例如，重构POM的时候可能会删除或添加依赖，造成依赖版本变化，依赖范围变化，插件版本变化等等，这些变化可能会导致项目编译失败，或者测试失败。在自动化测试及构建的基础上，最好能够有持续集成环境，以保证POM的修改可能造成的问题能够及时的被发现和修复。笔者目前工作的项目有一个对应的持续集成任务，该任务基于Hudson，每10分钟检查一次SCM，如果发现变更则构建项目，并反馈结果。这样，我就不用担心自己修改POM会引入潜在的问题。
增还是删
有时候这个答案是很显然的，当你的POM中存在一些依赖或者插件配置，但实际代码没有用到这些配置的时候，应该尽早删掉它们以免给人带来困惑。
还有一种常见的情况，我们可以删掉一些POM的元素，例如POM中配置了继承，当前模块与父模块使用同样的groupId和version时，就可以将
4.0.0 com.juvenxu.sample sample-parent 0.0.1-SNAPSHOT sample-foo jar ...
上述配置就sample-foo就没有groupId和version，需要注意的是，artifactId是不能被删除的，因为该元素不能也不应该被继承，父子模块应当使用不同的artifactId值。
除了删之外，有些时候我们还需要在POM中增加一些XML元素，目的是为了让POM更清晰易读，且保证Maven构建的稳定性。考虑如下的插件配置：
maven-compiler-plugin 1.5 1.5
虽然没有groupId及version，但这段配置是完全合法的。当插件没有groupId配置的时候，Maven会认为它是官方插件而自动使用org.apache.maven.plugins作为groupId，当插件没有version配置的时候，Maven则会使用最新的版本（Maven 2会使用最新的版本，包括SNAPSHOT，而Maven 3则只使用最新的非SNAPSHOT版本）。这段配置有两个问题，首先，如果让一个不熟悉Maven的开发者来看这段配置，他会感到费解，groupId和version究竟是什么呢？这与不清晰的代码是一个意思，有时候一些程序员为了让代码更短，会采用一些奇怪的语法和变量名，虽然代码量是少了，但沟通成本增加了，得不偿失。其次，让Maven猜测版本会有潜在的风险，因为插件的最新版本可能会变化，而这种变化对于Maven使用者来说通常是隐藏的，特别是在Maven 2中，甚至可能引入SNAPSHOT版本的插件，这是非常危险的。基于这两个原因，使用插件的时候，我们应当配置清楚groupId和version，如：
org.apache.maven.plugins maven-compiler-plugin 2.3.2 1.5 1.5
基于类似的原因，在配置项目依赖的时候，我们也应当一直显式地写明依赖版本，以避免Maven在不同的时刻引入不同版本的依赖而导致项目构建的不稳定。
除了上面提到的增删点之外，Maven官方还提供了一个非常有用的Maven Dependency Plugin来帮助我们分析项目中哪些依赖配置应该删除，那些依赖配置应该增加。Maven Dependency Plugin的analyze目标能够帮助分析项目依赖，例如运行命令 mvn dependency:analyze ，可以看到如下输出：
[INFO] --- maven-dependency-plugin:2.1:analyze (default-cli) @ sample-bar --- [WARNING] Used undeclared dependencies found: [WARNING] org.springframework:spring-context:jar:2.5.6:compile [WARNING] Unused declared dependencies found: [WARNING] org.springframework:spring-core:jar:2.5.6:compile [WARNING] org.springframework:spring-beans:jar:2.5.6:compile [INFO] ------------------------------------------------------------------------
这里的 Used undeclared dependencies 是指那些在项目中直接使用到的，但没有在POM中配置的依赖。例如该例中可能项目中的一些类有关于spring-context的Java import声明，但spring-context这个依赖实际是通过传递性依赖进入classpath的，这就意味者潜在的风险。一般来说我们对直接依赖的版本变化会比较清楚，因为那是我们自己直接配置的，但对于传递性依赖的版本变化，就会比较模糊，当这种变化造成构建失败的时候，就很难找到原因。因此我们应当增加这些 Used undeclared dependencies 。
依赖分析还提供了 Unused declared dependencies 供我们参考，这表示那些我们配置了，但并未直接使用的依赖。需要注意的时，对于这些依赖，我们不该直接简单地删除。由于dependency:analyze只分析编译主代码和测试代码使用的依赖，一些执行测试和运行时的依赖它发现不了，因此还需要人工分析。通常情况，Unused declared dependencies 还是能帮助我们发现一些无用的依赖配置。
最后，还一些重要的POM内容通常被大多数项目所忽略，这些内容不会影响项目的构建，但能方便信息的沟通，它们包括项目URL，开发者信息，SCM信息，持续集成服务器信息等等，这些信息对于开源项目来说尤其重要。对于那些想了解项目的人来说，这些信息能他们帮助找到想要的信息，基于这些信息生成的Maven站点也更有价值。相关的POM配置很简单，如：
... ... ... ... ... ... ... ... ...
小结
无论是对POM内容进行增还是删，其目的都是一样的，就是为了让POM更清晰易懂且让构建更稳定。从这点来说，POM重构与一般的代码重构是类似的。需要谨记的是，重构的前提是完善的自动化测试和持续集成。本文介绍的单个POM规模的重构，下篇文章笔者会介绍多模块项目的POM重构等内容。
关于作者
许晓斌（Juven Xu），国内社区公认的Maven技术专家、Maven中文用户组创始人、Maven技术的先驱和积极推动者。对Maven有深刻的认识，实战经验丰富，不仅撰写了大量关于Maven的技术文章，而且还翻译了开源书籍《Maven权威指南》，对Maven技术在国内的普及和发展做出了很大的贡献。就职于Maven之父的公司，负责维护Maven中央仓库，是Maven仓库管理器Nexus（著名开源软件）的核心开发者之一，曾多次受邀到淘宝等大型企业开展Maven方面的培训。此外，他还是开源技术的积极倡导者和推动者，擅长Java开发和敏捷开发实践。他的个人网站是：http://www.juvenxu.com。
Maven实战（三）——多模块项目的POM重构
作者 许晓斌 发布于 2011年1月9日
在本专栏的上一篇文章POM重构之增还是删中，我们讨论了一些简单实用的POM重构技巧，包括重构的前提——持续集成，以及如何通过添加或者删除内容来提高POM的可读性和构建的稳定性。但在实际的项目中，这些技巧还是不够的，特别值得一提的是，实际的Maven项目基本都是多模块的，如果仅仅重构单个POM而不考虑模块之间的关系，那就会造成无谓的重复。本文就讨论一些基于多模块的POM重构技巧。
重复，还是重复
程序员应该有狗一般的嗅觉，要能嗅到重复这一最常见的坏味道，不管重复披着怎样的外衣，一旦发现，都应该毫不留情地彻底地将其干掉。不要因为POM不是产品代码而纵容重复在这里发酵，例如这样一段代码就有重复：
org.springframework spring-beans 2.5 org.springframework spring-context 2.5 org.springframework spring-core 2.5
你会在一个项目中使用不同版本的SpringFramework组件么？答案显然是不会。因此这里就没必要重复写三次
2.5 org.springframework spring-beans ${spring.version} org.springframework spring-context ${spring.version} org.springframework spring-core ${spring.version}
现在2.5只出现在一个地方，虽然代码稍微长了点，但重复消失了，日后升级依赖版本的时候，只需要修改一处，而且也能避免漏掉升级某个依赖。
读者可能已经非常熟悉这个例子了，我这里再啰嗦一遍是为了给后面做铺垫，多模块POM重构的目的和该例一样，也是为了消除重复，模块越多，潜在的重复就越多，重构就越有必要。
消除多模块依赖配置重复
考虑这样一个不大不小的项目，它有10多个Maven模块，这些模块分工明确，各司其职，相互之间耦合度比较小，这样大家就能够专注在自己的模块中进行开发而不用过多考虑他人对自己的影响。（好吧，我承认这是比较理想的情况）那我开始对模块A进行编码了，首先就需要引入一些常见的依赖如JUnit、Log4j等等：
junit junit 4.8.2 test log4j log4j 1.2.16
我的同事在开发模块B，他也要用JUnit和Log4j（我们开会讨论过了，统一单元测试框架为JUnit而不是TestNG，统一日志实现为Log4j而不是JUL，为什么做这个决定就不解释了，总之就这么定了）。同事就写了如下依赖配置：
junit junit 3.8.2 log4j log4j 1.2.9
看出什么问题来没有？对的，他漏了JUnit依赖的scope，那是因为他不熟悉Maven。还有什么问题？对，版本！虽然他和我一样都依赖了JUnit及Log4j，但版本不一致啊。我们开会讨论没有细化到具体用什么版本，但如果一个项目同时依赖某个类库的多个版本，那是十分危险的！OK，现在只是两个模块的两个依赖，手动修复一下没什么问题，但如果是10个模块，每个模块10个依赖或者更多呢？看来这真是一个泥潭，一旦陷进去就难以收拾了。
好在Maven提供了优雅的解决办法，使用继承机制以及dependencyManagement元素就能解决这个问题。注意，是dependencyMananget而非dependencies。也许你已经想到在父模块中配置dependencies，那样所有子模块都自动继承，不仅达到了依赖一致的目的，还省掉了大段代码，但这么做是有问题的，例如你将模块C的依赖spring-aop提取到了父模块中，但模块A和B虽然不需要spring-aop，但也直接继承了。dependencyManagement就没有这样的问题，dependencyManagement只会影响现有依赖的配置，但不会引入依赖。例如我们可以在父模块中配置如下：
junit junit 4.8.2 test log4j log4j 1.2.16
这段配置不会给任何子模块引入依赖，但如果某个子模块需要使用JUnit和Log4j的时候，我们就可以简化依赖配置成这样：
junit junit log4j log4j
现在只需要groupId和artifactId，其它元素如version和scope都能通过继承父POM的dependencyManagement得到，如果有依赖配置了exclusions，那节省的代码就更加可观。但重点不在这，重点在于现在能够保证所有模块使用的JUnit和Log4j依赖配置是一致的。而且子模块仍然可以按需引入依赖，如果我不配置dependency，父模块中dependencyManagement下的spring-aop依赖不会对我产生任何影响。
也许你已经意识到了，在多模块Maven项目中，dependencyManagement几乎是必不可少的，因为只有它是才能够有效地帮我们维护依赖一致性。
本来关于dependencyManagement我想介绍的也差不多了，但几天前和Sunng的一次讨论让我有了更多的内容分享。那就是在使用dependencyManagement的时候，我们可以不从父模块继承，而是使用特殊的import scope依赖。Sunng将其列为自己的Maven Recipe #0，我再简单介绍下。
我们知道Maven的继承和Java的继承一样，是无法实现多重继承的，如果10个、20个甚至更多模块继承自同一个模块，那么按照我们之前的做法，这个父模块的dependencyManagement会包含大量的依赖。如果你想把这些依赖分类以更清晰的管理，那就不可能了，import scope依赖能解决这个问题。你可以把dependencyManagement放到单独的专门用来管理依赖的POM中，然后在需要使用依赖的模块中通过import scope依赖，就可以引入dependencyManagement。例如可以写这样一个用于依赖管理的POM：
4.0.0 com.juvenxu.sample sample-dependency-infrastructure pom 1.0-SNAPSHOT junit junit 4.8.2 test log4j log4j 1.2.16
然后我就可以通过非继承的方式来引入这段依赖管理配置：
com.juvenxu.sample sample-dependency-infrastructure 1.0-SNAPSHOT pom import junit junit log4j log4j
这样，父模块的POM就会非常干净，由专门的packaging为pom的POM来管理依赖，也契合的面向对象设计中的单一职责原则。此外，我们还能够创建多个这样的依赖管理POM，以更细化的方式管理依赖。这种做法与面向对象设计中使用组合而非继承也有点相似的味道。
消除多模块插件配置重复
与dependencyManagement类似的，我们也可以使用pluginManagement元素管理插件。一个常见的用法就是我们希望项目所有模块的使用Maven Compiler Plugin的时候，都使用Java 1.5，以及指定Java源文件编码为UTF-8，这时可以在父模块的POM中如下配置pluginManagement：
org.apache.maven.plugins maven-compiler-plugin 2.3.2 1.5 1.5 UTF-8
这段配置会被应用到所有子模块的maven-compiler-plugin中，由于Maven内置了maven-compiler-plugin与生命周期的绑定，因此子模块就不再需要任何maven-compiler-plugin的配置了。
与依赖配置不同的是，通常所有项目对于任意一个依赖的配置都应该是统一的，但插件却不是这样，例如你可以希望模块A运行所有单元测试，模块B要跳过一些测试，这时就需要配置maven-surefire-plugin来实现，那样两个模块的插件配置就不一致了。这也就是说，简单的把插件配置提取到父POM的pluginManagement中往往不适合所有情况，那我们在使用的时候就需要注意了，只有那些普适的插件配置才应该使用pluginManagement提取到父POM中。
关于插件pluginManagement，Maven并没有提供与import scope依赖类似的方式管理，那我们只能借助继承关系，不过好在一般来说插件配置的数量远没有依赖配置那么多，因此这也不是一个问题。
小结
关于Maven POM重构的介绍，在此就告一段落了。基本上如果你掌握了本篇和上一篇Maven专栏讲述的重构技巧，并理解了其背后的目的原则，那么你肯定能让项目的POM变得更清晰易懂，也能尽早避免一些潜在的风险。虽然Maven只是用来帮助你构建项目和管理依赖的工具，POM也并不是你正式产品代码的一部分。但我们也应该认真对待POM，这有点像测试代码，以前可能大家都觉得测试代码可有可无，更不会去用心重构优化测试代码，但随着敏捷开发和TDD等方式越来越被人接受，测试代码得到了开发人员越来越多的关注。因此这里我希望大家不仅仅满足于一个“能用”的POM，而是能够积极地去修复POM中的坏味道。
关于作者
许晓斌（Juven Xu），国内社区公认的Maven技术专家、Maven中文用户组创始人、Maven技术的先驱和积极推动者。对Maven有深刻的认识，实战经验丰富，不仅撰写了大量关于Maven的技术文章，而且还翻译了开源书籍《Maven权威指南》，对Maven技术在国内的普及和发展做出了很大的贡献。就职于Maven之父的公司，负责维护Maven中央仓库，是Maven仓库管理器Nexus（著名开源软件）的核心开发者之一，曾多次受邀到淘宝等大型企业开展Maven方面的培训。此外，他还是开源技术的积极倡导者和推动者，擅长Java开发和敏捷开发实践。他的个人网站是：http://www.juvenxu.com。
Maven实战（五）——自动化Web应用集成测试
作者 许晓斌 发布于 2011年3月13日
自动化集成测试的角色
本专栏的上一篇文章讲述了Maven与持续集成的一些关系及具体实践，我们都知道，自动化测试是持续集成必不可少的一部分，基本上，没有自动化测试的持续集成，都很难称之为真正的持续集成。我们希望持续集成能够尽早的暴露问题，但这远非配置一个 Hudson/Jenkins服务器那么简单，只有真正用心编写了较为完整的测试用例，并一直维护它们，持续集成才能孜孜不倦地运行测试并第一时间报告问题。
自动化测试这个话题很大，本文不想争论测试先行还是后行，这里强调的是测试的自动化，并基于具体的技术（Maven、 JUnit、Jetty等）来介绍一种切实可行的自动化Web应用集成测试方案。当然，自动化测试还包括单元测试、验收测试、性能测试等，在不同的场景下，它们都能为软件开发带来极大的价值。本文仅限于讨论集成测试，主要是因为笔者觉得这是一个非常重要却常常被忽略的实践。
基于Maven的一般流程
集成测试与单元测试最大的区别是它需要尽可能的测试整个功能及相关环境，对于测试Web应用而言，通常有这么几步：
-
启动Web容器
-
部署待测试Web应用
-
以Web客户端的角色运行测试用例
-
停止Web容器
启动Web容器可以有很多方式，例如你可以通过Web容器提供的API采用编程的方式来启动容器，但在Maven的环境下，配置插件显得更简单。如果你了解Maven的生命周期模型，就可能会想到，我们可以在pre-integration-test阶段启动容器，部署待测试应用，然后在integration-test阶段运行集成测试用例，最后在post-integrate-test阶段停止容器。也就是说，对于步骤1，2和4我们只须进行一些简单的配置，不必编写额外的代码。第3步是以黑盒的形式模拟客户端进行测试，需要注意的是，这里通常要求你理解一些基本的HTTP协议知识，例如服务端在什么情况下应该返回HTTP代码 200，什么时候应该返回401错误，以及所支持的Content-Type是什么等等。
至于测试用例该怎么写，除了需要用到一些用来访问Web以及解析响应详细的基础设施工具类之外，其他内容与单元测试大同小异，基本就是准备测试数据、访问服务、验证返回值等等。
一个简单的例子
谈了不少理论，现在该给个具体的例子了，譬如现在有个简单的Servlet，它接受参数a和b，做加法后返回二者之和，如果参数不完整，则返回HTTP 400错误，表示客户端的请求有问题。
public class AddServlet
extends HttpServlet
{
@Override
protected void doGet( HttpServletRequest req, HttpServletResponse resp )
throws ServletException,
IOException
{
String a = req.getParameter( "a" );
String b = req.getParameter( "b" );
if ( a == null || b == null )
{
resp.setStatus( 400 );
return;
}
int result = Integer.parseInt( a ) + Integer.parseInt( b );
resp.setStatus( 200 );
resp.getWriter().print( result );
}
}
为了测试这段代码，我们需要一个Web容器，这里暂且使用Jetty，因为目前来说它与Maven集成的相对最好。Jetty提供了一个Jetty Maven Plugin，借助该插件，我们可以随时启动Jetty并部署Maven默认目录布局的Web项目，实现快速开发和测试。这里我们需要的是在pre-integration-test阶段启动Jetty，在post-integrate-test阶段停止容器，对应的POM配置如下：
org.mortbay.jetty jetty-maven-plugin 7.3.0.v20110203 9966 stop-jetty-for-it start-jetty pre-integration-test run true stop-jetty post-integration-test stop
XML代码中第一处configuration是插件的全局配置，stopPort和 stopKey是该插件用来停止Jetty需要用到的TCP端口及消息关键字。接着是两个executation元素，第一个executation将 jetty-maven-plugin的run目标绑定至Maven的pre-integration-test生命周期阶段，表示启动容器，第二个 executation将stop目标绑定至post-integration-test生命周期阶段，表示停止容器。需要注意的是，启动Jetty时我们需要配置deamon为true，让Jetty在后台运行以免阻塞mvn命令。此外，jetty-maven-plugin的run目标也会自动部署当前Web项目。
准备好Web容器环境之后，我们接着看一下测试用例代码：
public class AddServletIT
{
@Test
public void addWithParametersAndSucceed()
throws Exception
{
HttpClient httpclient = new DefaultHttpClient();
HttpGet httpGet = new HttpGet( "http://localhost:8080/add?a=1&b=2" );
HttpResponse response = httpclient.execute( httpGet );
Assert.assertEquals( 200, response.getStatusLine().getStatusCode() );
Assert.assertEquals( "3", EntityUtils.toString( response.getEntity() ) );
}
@Test
public void addWithoutParameterAndFail()
throws Exception
{
HttpClient httpclient = new DefaultHttpClient();
HttpGet httpGet = new HttpGet( "http://localhost:8080/add" );
HttpResponse response = httpclient.execute( httpGet );
Assert.assertEquals( 400, response.getStatusLine().getStatusCode() );
}
}
为了能够访问应用，这里用到了HttpClient，两个测试方法都初始化一个HttpClient，然后创建HttpGet对象用来访问Web地址。第一个测试方法顾名思义用来测试成功的场景，它提供参数 a=1和b=2，执行请求后，验证返回结果成功（HTTP状态码200）并且内容为正确的值3。第二个测试方法则用来测试失败的场景，当不提供参数的时候，服务器应该返回一个HTTP 400错误。该测试类其实是相当粗糙的，例如有硬编码的服务器URL，这里的目的仅仅是通过尽可能简单的代码来展现一个自动化集成测试的实现过程。
上述代码中，测试类的名称为AddServletIT，而不是一般的**Test，IT表示IntegrationTest，这么命名是为了和单元测试区分开来，这样，鉴于Maven默认的测试命名约定，Maven在test生命周期阶段执行单元测试时，就不会涉及集成测试。现在，我们希望Maven在integration-test阶段执行所有以IT结尾命名的测试类，配置Maven Surefire Plugin如下：
org.apache.maven.plugins maven-surefire-plugin 2.7.2 run-integration-test integration-test test **/*IT.java
通过命名规则和插件配置，我们优雅地分离了单元测试和集成测试，而且我们知道在integration-test阶段，Jetty容器已经启动完成了。如果你在使用TestNG，那你还可以使用其测试组的特性来分离单元测试和集成测试，Maven Surefire Plugin对其也有着很好的支持。
一切就绪了，运行 mvn clean install 以自动运行集成测试，我们可以看到如下的输出片段：
[INFO] --- jetty-maven-plugin:7.3.0.v20110203:run (start-jetty) @ webapp-demo --- [INFO] Configuring Jetty for project: webapp-demo [INFO] webAppSourceDirectory /home/juven/git_juven/webapp-demo/src/main/webapp does not exist. Defaulting to /home/juven/git_juven/webapp-demo/src/main/webapp [INFO] Reload Mechanic: automatic [INFO] Classes = /home/juven/git_juven/webapp-demo/target/classes [INFO] Context path = / ... 2011-03-06 14:55:15.676:INFO::Started [email protected]:8080 [INFO] Started Jetty Server [INFO] [INFO] --- maven-surefire-plugin:2.7.2:test (run-integration-test) @ webapp-demo --- [INFO] Surefire report directory: /home/juven/git_juven/webapp-demo/target/surefire-reports ------------------------------------------------------- T E S T S ------------------------------------------------------- Running com.juvenxu.webapp.demo.AddServletIT Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.344 sec Results : Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- jetty-maven-plugin:7.3.0.v20110203:stop (stop-jetty) @ webapp-demo ---
可以看到jetty-maven-plugin:7.3.0.v20110203:run对应了start-jetty，maven-surefire- plugin:2.7.2:test对应了run-integration-test，jetty-maven- plugin:7.3.0.v20110203:stop对应了stop-jetty，与我们的配置和期望完全一致。此外两个测试也都成功了！
小结
相对于单元测试来说，集成测试更难编写，因为需要准备更多的环境，本文只涉及了Web容器最简单的情形，实际的开发情形中，你可能会遇到数据库，第三方Web服务，更复杂的容器配置和数据格式等等，这都使得编写集成测试变得让人畏惧。然而反过来考虑，无论如何你都需要测试，虽然这个自动化过程的投入很大，但收益往往更加客观，这不仅仅是手动测试时间的节省，更重要的是，你无法保证手动测试能被高频率的反复执行，也就无法保证问题能被尽早暴露。
对于Web应用来说，编写集成测试有助于你考虑和设计Web应用对外暴露的接口，这种“开发实现”/“测试审察”之间的角色转换往往能造就更清晰的设计，这也是编写测试最大的好处之一。
Maven用户能够得益于Maven的插件系统，不仅能节省大量的编码，还能得到稳定的工具，Jetty Maven Plugin和Maven Surefire Plugin就是最好的例子。本文只涉及了Jetty，如果读者的环境是Tomcat或者JBoss等其他容器，则需要查阅相关的文档以得到具体的实现细节，你可能对Tomcat Maven Plugin、JBoss Maven Plugin、或者Cargo Maven2 Plugin感兴趣。
关于作者
许晓斌（Juven Xu），国内社区公认的Maven技术专家、Maven中文用户组创始人、Maven技术的先驱和积极推动者。对Maven有深刻的认识，实战经验丰富，不仅撰写了大量关于Maven的技术文章，而且还翻译了开源书籍《Maven权威指南》，对Maven技术在国内的普及和发展做出了很大的贡献。就职于Maven之父的公司，负责维护Maven中央仓库，是Maven仓库管理器Nexus（著名开源软件）的核心开发者之一，曾多次受邀到淘宝等大型企业开展Maven方面的培训。此外，他还是开源技术的积极倡导者和推动者，擅长Java开发和敏捷开发实践。他的个人网站是：http://www.juvenxu.com。
Maven实战（六）——Gradle，构建工具的未来？
作者 许晓斌 发布于 2011年4月5日
Maven面临的挑战
软件行业新旧交替的速度之快往往令人咂舌，不用多少时间，你就会发现曾经大红大紫的技术已经成为了昨日黄花，当然，Maven也不会例外。虽然目前它基本上是Java构建的事实标准，但我们也能看到新兴的工具在涌现，比如基于Goovy的Gradle，而去年Hibernate宣布从Maven迁移至Gradle这一事件更是吸引了不少眼球。在此之前，我也听到了不少对Maven的抱怨，包括XML的繁冗，不够灵活，学习曲线陡峭等等。那Gradle是否能够在继承 Maven优点的基础上，克服这些缺点呢？带着这个疑问，我开始阅读Gradle的文档并尝试着将一个基于Maven的项目转成用Gradle构建，本文所要讲述大概就是这样的一个体验。需要注意的是，本文完全是基于Maven的角度来看Gradle的，因此对于Ant用户来说，视角肯定会大有不同。
Gradle初体验
Gradle的安装非常方便，下载ZIP包，解压到本地目录，设置 GRADLE_HOME 环境变量并将 GRADLE_HOME/bin 加到 PATH 环境变量中，安装就完成了。用户可以运行gradle -v命令验证安装，这些初始的步骤和Maven没什么两样。Gradle目前的版本是1.0-milestone-1，根据其Wiki上的Roadmap，在1.0正式版发布之前，还至少会有3个里程碑版本，而1.0的发布日期最快也不会早于6月份。而正是这样一个看起来似乎还不怎么成熟的项目，却有着让很多成熟项目都汗颜的文档，其包括了安装指南、基本教程、以及一份近300页的全面用户指南。这对于用户来说是非常友好的，同时也说明了Gradle的开发者对这个项目非常有信心，要知道编写并维护文档可不是件轻松的工作，对于Gradle这样未来仍可能发生很大变动的项目来说尤为如此。
类似于Maven的pom.xml文件，每个Gradle项目都需要有一个对应的build.gradle文件，该文件定义一些任务（task）来完成构建工作，当然，每个任务是可配置的，任务之间也可以依赖，用户亦能配置缺省任务，就像这样：
defaultTasks 'taskB'
task taskA << {
println "i'm task A"
}
task taskB << {
println "i'm task B, and I depend on " + taskA.name
}
taskB.dependsOn taskA
运行命令$ gradle -q之后（参数q让Gradle不要打印错误之外的日志），就能看到如下的预期输出：
i'm task A i'm task B, and I depend on taskA
这不是和Ant如出一辙么？的确是这样，这种“任务”的概念与用法与Ant及其相似。Ant任务是Gradle世界的第一公民，Gradle对Ant做了很好的集成。除此之外，由于Gradle使用的Grovvy脚本较XML更为灵活，因此，即使我自己不是Ant用户，我也仍然觉得Ant用户会喜欢上Gradle。
依赖管理和集成Maven仓库
我们知道依赖管理、仓库、约定优于配置等概念是Maven的核心内容，抛开其实现是否最优不谈，概念本身没什么问题，并且已经被广泛学习和接受。那Gradle实现了这些优秀概念了么？答案是肯定的。
先看依赖管理，我有一个简单的项目依赖于一些第三方类库包括SpringFramework、JUnit、Kaptcha等等。原来的Maven POM配置大概是这样的（篇幅关系，省略了部分父POM配置）：
2.3 com.google.code.kaptcha kaptcha ${kaptcha.version} jdk15 org.springframework spring-core org.springframework spring-beans org.springframework spring-context junit junit
然后我将其转换成Gradle脚本，结果是惊人的：
dependencies {
compile('org.springframework:spring-core:2.5.6')
compile('org.springframework:spring-beans:2.5.6')
compile('org.springframework:spring-context:2.5.6')
compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')
testCompile('junit:junit:4.7')
}
注意配置从原来的28行缩减至7行！这还不算我省略的一些父POM配置。依赖的groupId、artifactId、 version，scope甚至是classfier，一点都不少。较之于Maven或者Ant的XML配置脚本，Gradle使用的Grovvy脚本杀伤力太大了，爱美之心，人皆有之，相比于七旬老妇松松垮垮的皱纹，大家肯定都喜欢少女紧致的脸蛋，XML就是那老妇的皱纹。
关于Gradle的依赖管理起初我有一点担心，就是它是否有传递性依赖的机制呢？经过文档阅读和实际试验后，这个疑虑打消了，Gradle能够解析现有的Maven POM或者Ivy的XML配置，从而得到传递性依赖的信息，并且引入到当前项目中，这实在是一个聪明的做法。在此基础上，它也支持排除传递性依赖或者干脆关闭传递性依赖，其中第二点是Maven所不具备的特性。
自动化依赖管理的基石是仓库，Maven中央仓库已经成为了Java开发者不可或缺的资源，Gradle既然有依赖管理，那必然也得用到仓库，这当然也包括了Maven中央仓库，就像这样：
repositories {
mavenLocal()
mavenCentral()
mavenRepo urls: "http://repository.sonatype.org/content/groups/forge/"
}
这段代码几乎不用解释，就是在Gradle中配置使用Maven本地仓库、中央仓库、以及自定义地址仓库。在我实际构建项目的时候，能看到终端打印的下载信息，下载后的文件被存储在 USER_HOME/.gradle/cache/ 目录下供项目使用，这种实现的方法与Maven又是及其类似了，可以说Gradle不仅最大限度的继承Maven的很多理念，仓库资源也是直接拿来用。
Gradle项目使用Maven项目生成的资源已经不是个问题了，接着需要反过来考虑，Maven用户是否能够使用 Gradle生成的资源呢？或者更简单点问，Gradle项目生成的构件是否可以发布到Maven仓库中供人使用呢？这一点非常重要，因为如果做不到这一点，你可能就会丢失大量的用户。幸运的是Gradle再次给出了令人满意的答案。使用Gradle的Maven Plugin，用户就可以轻松地将项目构件上传到Maven仓库中：
apply plugin: 'maven'
...
uploadArchives {
repositories.mavenDeployer {
repository(url: "http://localhost:8088/nexus/content/repositories/snapshots/") {
authentication(userName: "admin", password: "admin123")
pom.groupId = "com.juvenxu"
pom.artifactId = "account-captcha"
}
}
}
在上传的过程中，Gradle能够基于build.gradle生成对应的Maven POM文件，用户可以自行配置POM信息，比如这里的groupId和artifactId，而诸如依赖配置这样的内容，Gradle是会自动帮你进行转换的。由于Maven项目之间依赖交互的直接途径就是仓库，而Gradle既能够使用Maven仓库，也能以Maven的格式将自己的内容发布到仓库中，因此从技术角度来说，即使在一个基于Maven的大环境中，局部使用Gradle也几乎不会是一个问题。
约定优于配置
如同Ant一般，Gradle给了用户足够的自由去定义自己的任务，不过同时Gradle也提供了类似Maven的约定由于配置方式，这是通过Gradle的Java Plugin实现的，从文档上看，Gradle是推荐这种方式的。Java Plugin定义了与Maven完全一致的项目布局：
-
src/main/java
-
src/main/resources
-
src/test/java
-
src/test/resources
区别在于，使用Groovy自定义项目布局更加的方便：
sourceSets {
main {
java {
srcDir 'src/java'
}
resources {
srcDir 'src/resources'
}
}
}
Gradle Java Plugin也定义了构建生命周期，包括编译主代码、处理资源、编译测试代码、执行测试、上传归档等等任务：
Figure 1. Gradle的构建生命周期
相对于Maven完全线性的生命周期，Gradle的构建生命周期略微复杂，不过也更为灵活，例如jar这个任务是用来打包的，它不像Maven那样依赖于执行测试的test任务，类似的，从图中可以看到，一个最终的build任务也没有依赖于uploadArchives任务。这个生命周期并没有将用户限制得很死，举个例子，我希望每次build都发布 SNAPSHOT版本到Maven仓库中，而且我只想使用最简单的$ gradle clean build命令，那只需要添加一行任务依赖配置即可：
build.dependsOn 'uploadArchives'
由于Gradle完全是基于灵活的任务模型，因此很多事情包括覆盖现有任务，跳过任务都非常易于实现。而这些事情，在Maven的世界中，实现起来就比较的麻烦，或者说Maven压根就不希望用户这么做。
小结
一番体验下来，Gradle给我最大的感觉是两点。其一是简洁，基于Groovy的紧凑脚本实在让人爱不释手，在表述意图方面也没有什么不清晰的地方。其二是灵活，各种在Maven中难以下手的事情，在Gradle就是小菜一碟，比如修改现有的构建生命周期，几行配置就完成了，同样的事情，在Maven中你必须编写一个插件，那对于一个刚入门的用户来说，没个一两天几乎是不可能完成的任务。
不过即使如此，Gradle在未来能否取代Maven，在我看来也还是个未知数。它的一大障碍就是Grovvy，几乎所有 Java开发者都熟悉XML，可又有几个人了解Groovy呢？学习成本这道坎是很难跨越的，很多人抵制Maven就是因为学起来不容易，你现在让因为一个构建工具学习一门新语言（即使这门语言和Java非常接近），那得到冷淡的回复几乎是必然的事情。Gradle的另外一个问题就是它太灵活了，虽然它支持约定优于配置，不过从本文你也看到了，破坏约定是多么容易的事情。人都喜欢自由，爱自定义，觉得自己的需求是多么的特别，可事实上，从Maven的流行来看，几乎95%以上的情况你不需要自行扩展，如果你这么做了，只会让构建变得难以理解。从这个角度来看，自由是把双刃剑，Gradle给了你足够的自由，约定优于配置只是它的一个选项而已，这初看起来很诱人，却也可能使其重蹈Ant的覆辙。Maven在Ant的基础上引入了依赖管理、仓库以及约定优于配置等概念，是一个很大的进步，不过在我现在看来，Gradle并没有引入新的概念，给我感觉它是一个结合Ant和Maven理念的优秀实现。
如果你了解Groovy，也理解Maven的约定优于配置，那试试Gradle倒也不错，尤其是它几乎能和现有的Maven系统无缝集成，而且你也能享受到简洁带来的极大乐趣。其实说到简洁，也许在不久的将来Maven用户也能直接享受到，Polyglot Maven在这方面已经做了不少工作。本文完全基于Maven的视角介绍Gradle这一构建工具的新秀，不过限于篇幅原因，无法深入Gradle的方方面面，例如Gradle也支持多模块构建，它提供了GUI操作界面，支持Grovvy（理所当然）和Scala项目等等。有兴趣的读者可以自行进一步了解。
关于作者
许晓斌（Juven Xu），国内社区公认的Maven技术专家、Maven中文用户组创始人、Maven技术的先驱和积极推动者，著有《Maven实战》一书。对Maven有深刻的认识，实战经验丰富，不仅撰写了大量关于Maven的技术文章，而且还翻译了开源书籍《Maven权威指南》，对Maven技术在国内的普及和发展做出了很大的贡献。就职于Maven之父的公司，负责维护Maven中央仓库，是Maven仓库管理器Nexus（著名开源软件）的核心开发者之一，曾多次受邀到淘宝等大型企业开展Maven方面的培训。此外，他还是开源技术的积极倡导者和推动者，擅长Java开发和敏捷开发实践。他的个人网站是：http://www.juvenxu.com。
Maven实战（九）——打包的技巧
作者 许晓斌 发布于 2011年6月20日
“打包“这个词听起来比较土，比较正式的说法应该是”构建项目软件包“，具体说就是将项目中的各种文件，比如源代码、编译生成的字节码、配置文件、文档，按照规范的格式生成归档，最常见的当然就是JAR包和WAR包了，复杂点的例子是Maven官方下载页面的分发包，它有自定义的格式，方便用户直接解压后就在命令行使用。作为一款”打包工具“，Maven自然有义务帮助用户创建各种各样的包，规范的JAR包和WAR包自然不再话下，略微复杂的自定义打包格式也必须支持，本文就介绍一些常用的打包案例以及相关的实现方式，除了前面提到的一些包以外，你还能看到如何生成源码包、Javadoc包、以及从命令行可直接运行的CLI包。
Packaging的含义
任何一个Maven项目都需要定义POM元素packaging（如果不写则默认值为jar）。顾名思义，该元素决定了项目的打包方式。实际的情形中，如果你不声明该元素，Maven会帮你生成一个JAR包；如果你定义该元素的值为war，那你会得到一个WAR包；如果定义其值为POM（比如是一个父模块），那什么包都不会生成。除此之外，Maven默认还支持一些其他的流行打包格式，例如ejb3和ear。你不需要了解具体的打包细节，你所需要做的就是告诉Maven，”我是个什么类型的项目“，这就是约定优于配置的力量。
为了更好的理解Maven的默认打包方式，我们不妨来看看简单的声明背后发生了什么，对一个jar项目执行mvn package操作，会看到如下的输出：
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ git-demo --- [INFO] Building jar: /home/juven/git_juven/git-demo/target/git-demo-1.2-SNAPSHOT.jar
相比之下，对一个war项目执行mvn package操作，输出是这样的：
[INFO] --- maven-war-plugin:2.1:war (default-war) @ webapp-demo --- [INFO] Packaging webapp [INFO] Assembling webapp [webapp-demo] in [/home/juven/git_juven/webapp-demo/target/webapp-demo-1.0-SNAPSHOT] [INFO] Processing war project [INFO] Copying webapp resources [/home/juven/git_juven/webapp-demo/src/main/webapp] [INFO] Webapp assembled in [90 msecs] [INFO] Building war: /home/juven/git_juven/webapp-demo/target/webapp-demo-1.0-SNAPSHOT.war
对应于同样的package生命周期阶段，Maven为jar项目调用了maven-jar-plugin，为war项目调用了maven-war-plugin，换言之，packaging直接影响Maven的构建生命周期。了解这一点非常重要，特别是当你需要自定义打包行为的时候，你就必须知道去配置哪个插件。一个常见的例子就是在打包war项目的时候排除某些web资源文件，这时就应该配置maven-war-plugin如下：
org.apache.maven.plugins maven-war-plugin 2.1.1 src/main/webapp **/*.jpg
源码包和Javadoc包
本专栏的《坐标规划》一文中曾解释过，一个Maven项目只生成一个主构件，当需要生成其他附属构件的时候，就需要用上classifier。源码包和Javadoc包就是附属构件的极佳例子。它们有着广泛的用途，尤其是源码包，当你使用一个第三方依赖的时候，有时候会希望在IDE中直接进入该依赖的源码查看其实现的细节，如果该依赖将源码包发布到了Maven仓库，那么像Eclipse就能通过m2eclipse插件解析下载源码包并关联到你的项目中，十分方便。由于生成源码包是极其常见的需求，因此Maven官方提供了一个插件来帮助用户完成这个任务：
org.apache.maven.plugins maven-source-plugin 2.1.2 attach-sources verify jar-no-fork
类似的，生成Javadoc包只需要配置插件如下：
org.apache.maven.plugins maven-javadoc-plugin 2.7 attach-javadocs jar
为了帮助所有Maven用户更方便的使用Maven中央库中海量的资源，中央仓库的维护者强制要求开源项目提交构件的时候同时提供源码包和Javadoc包。这是个很好的实践，读者也可以尝试在自己所处的公司内部实行，以促进不同项目之间的交流。
可执行CLI包
除了前面提到了常规JAR包、WAR包，源码包和Javadoc包，另一种常被用到的包是在命令行可直接运行的CLI（Command Line）包。默认Maven生成的JAR包只包含了编译生成的.class文件和项目资源文件，而要得到一个可以直接在命令行通过java命令运行的JAR文件，还要满足两个条件：
- JAR包中的/META-INF/MANIFEST.MF元数据文件必须包含Main-Class信息。
- 项目所有的依赖都必须在Classpath中。
Maven有好几个插件能帮助用户完成上述任务，不过用起来最方便的还是maven-shade-plugin，它可以让用户配置Main-Class的值，然后在打包的时候将值填入/META-INF/MANIFEST.MF文件。关于项目的依赖，它很聪明地将依赖JAR文件全部解压后，再将得到的.class文件连同当前项目的.class文件一起合并到最终的CLI包中，这样，在执行CLI JAR文件的时候，所有需要的类就都在Classpath中了。下面是一个配置样例：
org.apache.maven.plugins maven-shade-plugin 1.4 package shade com.juvenxu.mavenbook.HelloWorldCli
上述例子中的，我的Main-Class是com.juvenxu.mavenbook.HelloWorldCli，构建完成后，对应于一个常规的hello-world-1.0.jar文件，我还得到了一个hello-world-1.0-cli.jar文件。细心的读者可能已经注意到了，这里用的是cli这个classifier。最后，我可以通过java -jar hello-world-1.0-cli.jar命令运行程序。
自定义格式包
实际的软件项目常常会有更复杂的打包需求，例如我们可能需要为客户提供一份产品的分发包，这个包不仅仅包含项目的字节码文件，还得包含依赖以及相关脚本文件以方便客户解压后就能运行，此外分发包还得包含一些必要的文档。这时项目的源码目录结构大致是这样的：
pom.xml src/main/java/ src/main/resources/ src/test/java/ src/test/resources/ src/main/scripts/ src/main/assembly/ README.txt
除了基本的pom.xml和一般Maven目录之外，这里还有一个src/main/scripts/目录，该目录会包含一些脚本文件如run.sh和run.bat，src/main/assembly/会包含一个assembly.xml，这是打包的描述文件，稍后介绍，最后的README.txt是份简单的文档。
我们希望最终生成一个zip格式的分发包，它包含如下的一个结构：
bin/ lib/ README.txt
其中bin/目录包含了可执行脚本run.sh和run.bat，lib/目录包含了项目JAR包和所有依赖JAR，README.txt就是前面提到的文档。
描述清楚需求后，我们就要搬出Maven最强大的打包插件：maven-assembly-plugin。它支持各种打包文件格式，包括zip、tar.gz、tar.bz2等等，通过一个打包描述文件（该例中是src/main/assembly.xml），它能够帮助用户选择具体打包哪些文件集合、依赖、模块、和甚至本地仓库文件，每个项的具体打包路径用户也能自由控制。如下就是对应上述需求的打包描述文件src/main/assembly.xml：
bin zip true lib / README.txt src/main/scripts /bin run.sh run.bat
- 首先这个assembly.xml文件的id对应了其最终生成文件的classifier。
- 其次formats定义打包生成的文件格式，这里是zip。因此结合id我们会得到一个名为hello-world-1.0-bin.zip的文件。（假设artifactId为hello-world，version为1.0）
- dependencySets用来定义选择依赖并定义最终打包到什么目录，这里我们声明的一个depenencySet默认包含所有所有依赖，而useProjectArtifact表示将项目本身生成的构件也包含在内，最终打包至输出包内的lib路径下（由outputDirectory指定）。
- fileSets允许用户通过文件或目录的粒度来控制打包。这里的第一个fileSet打包README.txt文件至包的根目录下，第二个fileSet则将src/main/scripts下的run.sh和run.bat文件打包至输出包的bin目录下。
打包描述文件所支持的配置远超出本文所能覆盖的范围，为了避免读者被过多细节扰乱思维，这里不再展开，读者若有需要可以去参考这份文档。
最后，我们需要配置maven-assembly-plugin使用打包描述文件，并绑定生命周期阶段使其自动执行打包操作：
org.apache.maven.plugins maven-assembly-plugin 2.2.1 src/main/assembly/assembly.xml make-assembly package single
运行mvn clean package之后，我们就能在target/目录下得到名为hello-world-1.0-bin.zip的分发包了。
小结
打包是项目构建最重要的组成部分之一，本文介绍了主流Maven打包技巧，包括默认打包方式的原理、如何制作源码包和Javadoc包、如何制作命令行可运行的CLI包、以及进一步的，如何基于个性化需求自定义打包格式。这其中涉及了很多的Maven插件，当然最重要，也是最为复杂和强大的打包插件就是maven-assembly-plugin。事实上Maven本身的分发包就是通过maven-assembly-plugin制作的，感兴趣的读者可以直接查看源码一窥究竟。
Maven实战（十）——Maven 3，是时候升级了
作者 许晓斌 发布于 2011年7月27日
去年10月份Apache Maven发布了3.0正式版，而在上个月的22号，Eclipse基金会宣布了Eclipse 3.7（Indigo）的发布，该版本Eclipse最大的新特性之一就是集成了Maven。下载Eclipse IDE for Java Developers版本的用户会发现，Eclipse已经能够自动识别Maven项目了。Indigo中内置的Maven版本是3.0.2，这在一定程度上说明Maven 3已经非常稳定了。不过我相信一定还有很多Maven 2用户在犹豫是否升级，本文会介绍一些Maven 3最重要的特性，旨在帮助读者扫除疑虑，尽早享受Maven 3所能带来的各种便利。
确保兼容性
在升级软件的时候，兼容性显然是首先要考虑的问题，如果原本在Maven 2下能成功构建的项目，在Maven 3下立刻就失败了，而且难以简单修复，那显然是不可接受的。 好在Maven用户大可打消这一顾虑，Maven 3自设计之初就一直考虑与Maven 2的兼容性，这不仅是指兼容Maven 2的核心，还包括大量的org.apache.maven.plugins与org.codehaus.mojo插件。虽然由于某些插件代码的特殊性，无法做到100%完全的兼容，但已经基本不会遇到问题了。
如果你还有担心，那可以先仔细阅读官方发布的Maven 3.x兼容性笔记和Maven 3.x插件兼容性列表。这两份文档记录的兼容性问题主要涉及的是一些应当被弃用的特性，并且都给出了Maven 3下的解决方案。
改进性能
Maven 3的性能较之于Maven 2是有了很大的进步的，这体现在内存占用的减少和构建时间的减少两个方面。特别是Maven 3引入的并行构建特性，能够分析项目模块之间的依赖关系，然后并行地构建那些相互间没有依赖关系的模块，从而充分利用如今普遍的多核CPU资源。
以下两条命令分别表示用4个线程构建，以及根据CPU核数每个核分配1个线程进行构建：
$ mvn -T 4 clean install $ mvn -T 1C clean install
Maven的提交者之一Anders Hammar在其文章迁移到Maven 3的十大理由中介绍了一个简单的实验，分别用Maven 2.2.1，Maven 3.0.2（单线程），和Maven 3.0.2（4线程）构建同样的包含32个模块的Maven源代码，得到了如下的结果：
| 时间/内存 | |
| Maven 2.2.1 | 3:20/53M |
| Maven 3.0.2（单线程） | 3:15/27M |
| Maven 3.0.2（4线程） | 2:26/28M |
可以看到Maven 3下内存的占用减少了近一半！而开启并行构建后，时间的节省也是非常可观的。而项目越大，这种性能的改进就越为明显。如果你的开发环境没有充裕的内存，而你的项目又非常大，那光内存节省这一条就足以让你立刻转向Maven 3了。
改进模块间依赖解析
Maven 2中一个比较令人头疼的问题是，当你在构建一个多模块项目的时候，为了使前面的模块能在后面模块classpath中生效，你必须将其install到本地仓库中之后，Maven才能解析使用。几乎所有Maven 2用户或早或晚都遇到了这个困惑，“为什么我已经 mvn clean package 了模块A，可构建模块B的时候还是无法看到A的更新呢？”这个问题在Maven 3中得以解决了，在构建多模块项目的时候，Maven 3会从反应堆（reactor）中解析模块间依赖，也就是说只要模块A执行了package，那模块B就能根据相对路径找到并解析使用A生成的jar文件。
提倡最佳实践
刚从Maven 2转到Maven 3的用户很可能会发现执行构建的时候命令行会打印很多如下的警告：
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing. [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
大部分如下的警告是因为用户在配置插件或者依赖的时候没有指定版本，无法保证构建的可重现性，从而为构建引入了潜在的风险。这样的警告是一种既保持兼容性，又提倡最佳实践而做出的权衡。类似的改进还包括弃用profile.xml特性、明确分离项目依赖和插件依赖等等。
改进日志输出
这是一个很微小的改进，却突显了Maven开发者对Maven用户的关怀，我个人非常喜欢这点改进。简单得来说，Maven 3的构建日志更容易阅读了。插件的输出之间都有空行隔开，每个被运行插件的版本、目标、以及所处模块的artifactId都得以清晰显示。当构建出现错误的时候，这样的输出能帮助用户更快地找到问题所在。
站点（注意！）
站点这一特性是Maven 2的核心，但是在Maven 3中，该特性被完全移到了maven-site-plugin中，这就导致了相关的配置也需要转移。Maven 2中与站点相关的配置是在POM的reporting元素下的，如：
... org.apache.maven.plugins maven-javadoc-plugin 2.7
在Maven 3中，所有站点相关的配置都应该出现在maven-site-plugin下面：
... ... ... org.apache.maven.plugins maven-site-plugin 3.0-beta-3 org.apache.maven.plugins maven-javadoc-plugin 2.7
小结与致谢
本文从兼容性、新特性、性能改进、以及重要细节等方面全面介绍了Maven 3。Maven 3是Maven从成熟走向巅峰的标志，如果你还未升级，我强烈建议你至少尝试一下，Maven的安装是非常简单的，只需要下载一个zip包、解压、然后设置简单的环境变量即可，马上去下载吧！
由于能力及精力所限，我已经很难再写更多既不重复又符合很多读者口味的Maven文章，因此暂且计划将该专栏告一段落。我衷心感谢张凯峰的策划和编辑，感谢读者的支持，另外也感谢我的家人，特别是我三岁的女儿，那些给写稿的时间本该属于她们。最后，我还是会持续关心 Maven的发展，有机会也一定会分享更多的经验和心得。