最近遇到了一个 Maven 的小问题，着实让有2年多的 Java 实战开发经验的笔者留了一身汗。自以为对 Maven 的常用东西还是比较熟悉的，实际还是停留在 “知其然而不知其所以然” 的阶段。习惯了 “临摹官方示例＋遇到问题就搜索” 的快餐式手法，自然就渐渐失去刨根问底的心，是吧。
所以本篇旨在记录所遇到问题的解决过程，以及从 “技术小白” （我还是很谦虚的好不 🐶） 的视角来看看 Maven 工具的一些“小技巧”。
问题：咦，集成测试挑机器，死活跑不起来？
为了测试 redis 实现的 repository，使用了 embedded-redis，在测试前可以开启一个嵌入式的 redis server，跑完测试只需要 server.stop() 就好了。这一套在我的 Macbook Pro 上跑得好好的，换到另一个同事的 Windows 上就死活报错说 server 起不来，但其实 embedded-redis 是支持 windows的。
本着不想折腾 embedded-redis 配置的原则，咱来个曲线救国吧，让一部分测试成为可选项，只按需的跑一跑（不在开发本地跑，只在 Jenkins 上跑）。自然的就想到了将一部分测试作为 Integration Test，通过配置来控制它们的运行。
然而，这次运气就没那么好了，除非在 maven surefire plugin 中配置 Skip Test 或者使用 mvn install -DskipTests，似乎没有办法在 mvn install 的时候不去运行集成测试。
1. 无痛起步：mvn clean install ？
从我两年前第一天上班起，这个三个英文字母就跟打了烙印一样深刻。拿到项目代码，啥事儿不管，咱先实现个小目标，比如一次性跑通 mvn clean install。所以说 “入门教程” 他害人不浅呐，直到几天前，我都还以为本地编译打包用这 “一招鲜” 就可以了。
首先我们来看看 Maven 的 Lifecycle 吧，完整的 Lifecycle 还包含很多中间步骤。
- validate：验证一些东西，我也不知道是啥 🐱
- compile：编译
- test：单元测试
- package：打包成 jar 或者其他形式
- verify：集成测试
- install：安装到 maven repository
- deploy：部署上传到仓库
看到这里，读者可能意识到了什么吧，其实有个最直截了当的做法，丫的你只运行 mvn package 不就好了🐶。可是……俺就想跑个 mvn install 怎么办！（参考后面的“打包所有的 jar”，因为某插件是在 install 的阶段才执行）
2. Test 原来可以优雅的分为两类
补充一点，前面提到了单元测试 (UnitTest) 和集成测试 (IntegrationTest)，如何让一部分测试成为集成测试呢。有一种简单直接的办法就是手动配置标记那些测试文件（文件夹）只在集成测试的时候才运行。
其实工具已经提供了一个优雅的办法来区分哪些是单元测试，哪些是集成测试。在后文中要用的集成测试插件maven-surefire-plugin、maven-failsafe-plugin 都有个 include的约定：
Unit Test 文件命名约定：凡是以 Test 作为文件名的开头或结尾的那些测试自动归类为单元测试。
Integration Test 文件命名约定：凡是以 IT 作为文件名的开头或结尾的那些测试自动归类为集成测试。
如此，在 “约定大于配置” 之下，很多事儿就自然优雅了。
3. 解法：Profile
下面来说说解法，这里笔者选择了 Maven 的 profile 来控制是否加入集成测试插件，在 all 的 profile 配置下，failsafe插件才生效，mvn install 才会去运行那些集成测试。
<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>all</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.19.1</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
大部分时候：我只想默默地完成 Build
mvn clean install
因为前面配置了 activeByDefault 的空 Profile，所以无需额外的说明，它只会跑所有的单元测试。
集成的时候：我也想来个大宝剑
mvn clean install -P all
在 Jenkins 配置上这个命令就可以跑完所有的测试流程了。
Maven 的一些常用配置补完
1. 打包所有的 jar
在我们的项目中，虽然使用了 spring-boot，但并没有使用插件来生产 fat-jar。 而是把所有的 jar 文件（包括众多的 dependencies）打包成一个文件归档，用于部署。下面就讲讲如何在 Maven 里来完成这个步骤。
使用插件打包所有的jar
这里使用了 “maven-dependency-plugin” 来复制所有的依赖 jar 到 target/lib 目录下， 然后 “maven-assembly-plugin” 插件会将可执行 jar 以及所有的依赖库 jar 按照 zip-package.xml 的配置去执行打包。如果你和我一样配置了 “finalName” 那么最终的输出文件名就会是例子中的 demo-service.tar.gz，否则它会默认根据你的 {artifactId}-{version} 来生成。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>create-distribution</id>
<phase>install</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>demo-service</finalName>
<descriptors>
<descriptor>zip-package.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
<includeScope>runtime</includeScope>
</configuration>
</execution>
</executions>
</plugin>
assembly 的配置
<?xml version="1.0" encoding="UTF-8"?>
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>dist</id>
<formats>
<format>tar.gz</format>
</formats>
<fileSets>
<fileSet>
<directory>${project.build.directory}</directory>
<outputDirectory>build</outputDirectory>
<includes>
<include>*.jar</include>
</includes>
<excludes>
<exclude>*-sources.jar</exclude>
</excludes>
</fileSet>
<fileSet>
<directory>${project.build.directory}/lib</directory>
<outputDirectory>lib</outputDirectory>
<includes>
<include>*.jar</include>
</includes>
</fileSet>
</fileSets>
</assembly>
上面贴的是我使用的 zip-package.xml ，打包的输出 format 使用 gzip 压缩，在 fileSet 里设置了 include/exclude 的文件，outputDirectory 可以用于设置文件的输出路径，上面例子中的配置生成的结构就是：
build/
|-- service.jar
lib/
|-- tomcat.jar
|-- tool.jar
|-- ...
2. 手动上传依赖的 jar 到 私有的 Nexus 里
某些时候，你项目里依赖的 jar lib 可能并没有在 public repository 里面，比如外包厂商生成的 jar。有一种做法是直接添加 sytem scope 的依赖：
<dependency>
<groupId>com.demo.www</groupId>
<artifactId>demo</artifactId>
<version>0.0.1</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/demo-0.0.1.jar</systemPath>
</dependency>
这么做不是不可以，但会看着很奇怪，依赖管理起来也很麻烦，某些时候还会遇到 bug （maven-dependency-plugin 里配置的 runtime includeScope 并不会把这个 system scope 的依赖放进去）
另一种做法就是把这个 jar 上传到你的 私有 Nexus 里面就行管理，用的时候保持平常的 dependency 规则就好了：
<dependency>
<groupId>com.demo.www</groupId>
<artifactId>demo</artifactId>
<version>0.0.1</version>
</dependency>
下面就给出笔者所使用的 bash 上传脚本，读者请按照你的实际情况修改即可，从此 pom 里无需system scope的依赖了。
mvn deploy:deploy-file \
-DgroupId=com.demo.www \
-DartifactId=demo \
-Dversion=0.0.1 \
-DgeneratePom=true \
-Dpackaging=jar \
-DrepositoryId=myrepository \
-Durl=http://myrepository.com/content/repositories/releases \
-Dfile=demo-sdk-java-0.0.1.jar
3. 其他的一些工具
- error-prone：google 出品必属精品，帮你做代码的静态检查，老司机（毕竟使用神器 Intellij）应该不怎么有机会触发它的警报。
- distributionManager: 当你使用私有的 Nexus 的时候需要配置的。
- aspectj-maven-plugin: 用于在编译期 weave 你的 AspectJ AOP，例子可以参考之前的一篇文章《Java AOP 实例踩坑记》。
最后：请手下留情
别问我 “你为啥不用 Gradle 呀”，我怎么好意思机智的回答说 “那是因为公司的技术太老旧了呀，只会用 Maven” 😅。就算我技多不压身，但精力有限，术业有专攻，我知道 Gradle 可以很方便的做很多 DevOps 的事情，可我只想做个安静的 Coder，也没必要折腾这么多种构建工具吧，以后用到了学起来就好了。
