mvn clean:
清空maven在构建过程中在target目录中产生的最终文件、中间文件等。clean生命周期分为三段：pre_clean、clean、post_clean，maven默认只做了clean这一段，清除文件；如果需要在清除以前做一些事情，比如统计target目录文件数目、大小等可以写一个maven插件并且绑定到clean生命周期的pre_clean阶段上。post_clean阶段亦然。
mvn package:
对项目进行打包，打包结果是在pom文件中配置好的。maven生命周期除了clean生命周期以外还有default生命周期，也是maven的核心生命周期；default生命周期包含validate、compile、test、install、deploy，分别绑定了maven自带的一些插件，每次执行一个mvn生命周期的命令，都是从validate开始，到命令定义的阶段为止，例如当执行mvn install时，maven先后执行了validate、compile、test以及install。这些生命周期阶段与对应的插件的绑定是在maven的root pom中设置的，对用户透明，当然也可以对其进行定制。
mvn clean install -e:
maven的两个生命周期相互独立，也可以组合使用，上面的命令就是先清空target目录再对项目进行install。-e命令的加入使得maven命令执行的错误信息得以打印在命令行，方便对错误进行排查，非常好用。
mvn clean install -Dmaven.test.skip=true -e:
-Dmaven.test.skip=true命令可以使得maven在生命周期执行过程中跳过test阶段，对于开发人员可以节省每次构建的时间。
mvn dependency:analyze -e:
分析项目中的依赖，输出为两个列表，使用了未声明的依赖（也就是间接依赖）列表，以及声明了未使用的依赖列表。应该尽量避免第一个列表中的信息，以免出现间接依赖被干掉了导致项目不能构建的问题。
maven的依赖管理使用<dependencyManagement>标签，这是一个依赖池的概念，整个项目所有的依赖以及依赖的版本信息都应该配置在该标签下。项目子工程需要使用到的依赖配置在<dependencies>标签下，此标签下地依赖应该都是<dependencyManagement>标签中已经定义过的依赖，不需要填写版本信息。
maven对于间接依赖的冲突解决有两个规则：
1.最短路径原则：A->B2.0->C2.0, A->D1.0->E1.0->C3.0，如果项目A有以上两种依赖，对已间接依赖C会取用C2.0版本，因为其路径比C3.0短。
2.先配置原则：A->B2.0->C2.0，A->D1.0->C3.0，这种情况需要看pom文件中B2.0的配置与D1.0配置的位置，如果B2.0写在前面，则采用C2.0。
mvn denpendency:tree -Dincludes=*:junit -Dverbose:
分析项目的依赖树，解决jar包冲突的最常用命令。加上参数-Dincludes=*:junit，则只打印artifactId为junit的依赖信息；加上-Dverbose则会打印出junit被依赖的整个过程。
mvn help:effective-pom/mvn help:effective-settings:
我们项目中配置的pom文件是非常简单的，而maven需要使用的时候会将项目中的pom文件分析并且与root pom文件合并成一个真实可用的文件。mvn help:effective-pom命令帮助会打印出这个可用的文件，以供排查问题。同理，mvn help:effective-settings会打印现在真实可用的配置文件。
mvn -T 2 clean install/mvn -T 2C clean install:
maven支持并行构建，-T 2表示使用2个线程进行构建， -T 2C表示使用双核进行构建。
最后，对于maven的版本，SNAPSHOT建议只在开发时期使用，一旦需要发布到线上，立马改成正式版本，以免别人构建的时候出现莫名其妙的错误。
原文地址：http://www.cnblogs.com/vanexu/p/3845446.html
