Maven 3 入门 -- 核心概念
坐标
例如上篇helloworld的pom.xml配置文件中的
<groupId>com.zhaoyang</groupId>
<artifactId>HelloWorld</artifactId>
<version>1.0-SNAPSHOT</version>
其实就是坐标，那么Maven的坐标元素包括groupId、artifactId、version、packaging、classifier
当一个项目通过依赖，插件或者父项目引用和另外一个项目关联的时候，Maven通过坐标来精确定位一个项目。
groupId： 团体，公司，小组，组织，项目，或者其它团体。团体标识的约定是，它以创
建这个项目的组织名称的逆向域名开头。
artifactId： 在groupId下的表示一个单独项目的唯一标识符
version： 定义项目的版本
packaging：打包方式，比如：jar或者war，默认是jar
classifier： 表示构件的jdk版本，我们不能直接定义
---------------------------------------------------------------------------------------------------------------------------------
我们把开始的HelloWorld项目安装到本地仓库，运行mvn clean install
那么现在去本地仓库目录下查看那个项目，我们就可以理解坐标在仓库中的构成
如下图：
注：maven的坐标并不仅仅只是指一个对应的jar文件，而是包括它的依赖等等等等，我们通过坐标可以精确的定位到这个maven项目。
Maven的生命周期（Life Cycle）
什么是生命周期？
生命周期是指我们对项目的清理，初始化，编译，测试，打包，集成测试，验证，部署，站点生产等等一系列的流程，但是每个公司都是用不同的方式来来做这些同样的事情，那么Maven它就给我们把这些过程（称为构建过程）进行了抽象和统一
Maven有三套独立的生命周期，它们分别是clean , default, site
1) clean 生命周期是用于清理项目 （默认是删除了target文件夹）
2) default 生命周期是用于构建项目
3) site 生命周期是是用于建立项目站点
clean生命周期
|
pre-clean |
清理之前的准备 |
|
clean |
进行清理工作，通常是干掉target文件夹 |
|
post-clean |
清理之后的准备工作 |
default生命周期
|
validate |
验证项目是否正确，以及所有为了完整构建必要的信息是否可用 |
|
initialize |
|
|
generate-sources |
生成所有需要包含在编译过程中的源代码 |
|
process-sources |
处理源代码，比如过滤一些值 |
|
generate-resources |
生成所有需要包含在打包过程中的资源文件 |
|
process-resources |
复制并处理资源文件至目标目录，准备打包 |
|
compile |
编译项目的源代码 |
|
process-classes |
处理编译生成的文件，例如对Java类进行字节码增强 |
|
generate-test-sources |
生成所有包含在测试编译过程中的测试源码 |
|
process-test-sources |
处理测试源码，比如过滤一些值 |
|
generate-test-resources |
生成测试需要的资源文件 |
|
process-test-resources |
复制并处理测试资源文件至测试目标目录 |
|
test-compile |
编译测试源码至测试目标目录 |
|
process-test-classes |
|
|
test |
使用合适的单元测试框架运行测试，这些测试应该不需要代码被打包或发布 |
|
prepare-package |
在真正的打包之前，执行一些准备打包必要的操作 |
|
package |
将编译好的代码打包成可分发的格式，如JAR，WAR，或者EAR |
|
pre-integration-test |
执行一些在集成测试运行之前需要的动作，如建立集成测试需要的环境 |
|
integration-test |
如果有必要的话，处理包并发布至集成测试可以运行的环境 |
|
post-integration-test |
执行一些在集成测试运行之后需要的动作，如清理集成测试环境。 |
|
verify |
执行所有检查，验证包是有效的，符合质量规范 |
|
install |
安装包至本地仓库，以备本地的其它项目作为依赖使用 |
|
deploy |
复制最终的包至远程仓库，共享给其它开发人员和项目 |
site生命周期
|
pre-site |
|
|
site |
|
|
post-site |
|
|
site-deploy |
|
注：在每个生命周期的不同阶段，如果执行了后面阶段的，前面的就会自动执行
比如我们执行
mvn clean 就相当于执行了 pre-clean 以及 clean
mvn test 就相当于执行了 validate --> initialize --> … -->compile-->…--->test
仓库
在Maven世界中，任何一个依赖、插件或者项目的构建输出，都可以称为构件。任何一个构件都有一组坐标唯一标识。
得益于坐标机制，任何Maven项目使用任何一个构件的方式都是完全相同的。在此基础上，Maven可以在某个位置统一存储所有Maven项目共享的构件，这个统一的位置就是仓库。
对于Maven来说，仓库只分为两大类：本地仓库和远程仓库。当Maven根据坐标寻找构件的时候，它首先会查看本地仓库，如果本地仓库存在此构件，则直接使用；如果本地仓库部存在此构件，Maven就会去远程仓库查找，发现需要的构件之后，下载到本地仓库再使用。
依赖管理（maven最强大的特性）
什么是依赖管理(Dependency Management)？
简单的说，比如我们的java项目一般都是会依赖其他的包，在maven的世界里，这些被依赖的包被称为dependency，就如开始我们配置文件中配置的一样，而dependency又是其他工程的坐标。
依赖的传递性（Transitive Dependencies）
在Maven中一个依赖不仅仅是一个JAR。它是一个POM文件，这个POM可能也声明了对其它构件的依赖。这些依赖的依赖叫做传递性依赖，Maven仓库不仅仅存贮二进制文件，也存储了这些构建的元数据（metadata）
比如假如你的项目依赖于一个库，而这个库又依赖于五个或者十个其它的库（就像Spring或者Hibernate那样）。你不必找出所有这些依赖然后把它们写在你的pom.xml里，你只需要加上你直接依赖的那些库，Maven会隐式的把这些库间接依赖的库也加入到你的项目
中。Maven也会处理这些依赖中的冲突，同时能让你自定义默认行为，或者排除一些特定的传递性依赖
Maven也提供了不同的依赖范围(dependency scope)，比如我们上个项目配置的JUNIT
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
其中的scope为test就是说明只有在运行测试编译的时候才会加入到classpath中
注：
当为项目创建JAR文件的时候，它的依赖不会被捆绑在生成的构件中，他们只是用来编
译。当用Maven来创建WAR或者EAR，你可以配置Maven让它在生成的构件中捆绑依赖，
你也可以配置Maven，使用provided范围，让它排除WAR文件中特定的依赖。provided范
围告诉Maven一个依赖在编译的时候需要，但是它不应该被捆绑在构建的输出中。当你
开发web应用的时候provided范围变得十分有用，你需要通过Servlet API来编译你的代
码，但是你不希望Servlet API的JAR文件包含在你web应用的WEB-INF/lib目录中。
