这篇文章对Maven中几个比较重要的概念坐标、依赖、仓库、生命周期做一个简单的介绍。
1、关于Maven坐标
用来区别Maven世界中任何一个构件，Maven坐标的元素包括groupId、artifactId、version、packaging、classifier，只要我们提供正确的坐标就能够访问对应的构件。
<groupId>org.springframework</groupId> //当前Maven项目隶属的实际项目，其下面可能按功能划分了很多子项目，spring-core、spring-context等 <artifactId>spring-core</artifactId> //当前项目名 <version>4.2.2.RELEASE</version> //项目版本 <packaging>jar</packaging> //Maven项目的打包方式
2、关于依赖
依赖应该是pom.xml文件中最常用到的东西了，用于把第三方的构件引入当前项目中。
1 <project> 2 ... 3 <dependencies> 4 <dependency> 5 <groupId>org.srpingframework</groupId> 6 <artifactId>spring-core</artifactId> 7 <version>1.0</version> //以上这三个标签确定依赖的坐标以便寻找构件 8 <scope>compile</scope> //依赖的范围 9 <optional>true</optional> //标记依赖是否可选 10 <exclusions> //排除传递性依赖 11 <exclusion> 12 ... 13 </exclusion> 14 <exclusions> 15 </dependency> 16 </dependencies> 17 </project>
依赖的范围：用来控制引入的依赖构件与三种classpath的关系(编译、测试、运行)，其中分为五种类型
compile: 编译依赖范围，对于编译、测试、运行都有效，在这三种情况下都需要该依赖的时候使用该依赖，spring-core。
test: 测试依赖范围，该依赖只在测试时有效，编译主代码或运行时该依赖无效，最常见的例子是junit。
provided: 已提供依赖范围，编译测试有效，运行无效，典型的例子servlet-api，因为运行的时候tomcat容器已经提供了servlet-api，所以不再需要重复提供。
runtime: 运行时依赖，测试运行有效
system: 系统依赖范围，于classpath的关系和provided完全一致，但是依赖不是来自于Maven，而是从本地引入，一般不推荐使用。
import:
传递性依赖：A-->B-->C，A依赖B,B依赖C，那么由于B的中间依赖作用A也会依赖C。
依赖的调节：当我们同时引入了两个或以上的相同依赖时无疑会出现问题，所以Maven根据以下这两个法则来确定引入那个版本的依赖
最短路劲依赖：A-->B-->C-->X(1)，A-->D-->X(2)，这种情况下会引入X(2)而舍弃X(1)依赖。
当依赖路劲相等的情况下，根据依赖出现的先后位置来确定引入何种依赖，顺序靠前的优先解析。
可选依赖: 比如说项目A依赖项目B，而B依赖X或者Y，B是持久层隔离工具包，支持多种数据库，依赖mysql或者oracle等，构建项目时需要他们的驱动程序，但是使用的时候只能依赖其中一种，这个时候就需要可选依赖了。可选依赖不会传递，也就是说X或者Y不会对A造成任何影响。
排除依赖：当我们需要排除这个依赖而引入另一个依赖时使用，例如Sun JTA API,Hibernate依赖这个jar，但是由于版权原因，该类库不存在于中央仓库中，而Apache中有一个对应的实现，这个时候就可以排除掉sun的这个依赖而引入apache的对应依赖。
<exclusions>声明要排除依赖的groupId artifactId 这里不需要version因为maven的pom文件里不能存在groupId artifactId相同而
version不同的依赖，所以只需要groupId artifactId就可以确定要排除的依赖
归类依赖：
假设在一个项目中有很多关于Spring Framework的依赖 org.springframework:spring-core:2.5.6 、org.springframework:spring-bean:2.5.6、
org.springframework:spring-context:2.5.6，他们都是来自一个项目的不同模块，假设我们要对Srping Framework进行升级，最好把version提取出来，
方便统一修改，类似于java中关于常量的作用，这里要用到<properties>。
<properties> <springframework.version>2.5.6</springframework.version> </properties> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${springframework.version}</version> </dependency> </dependencies>
3.仓库
分类：a、远程仓库 b、本地仓库(b1：中央仓库，b2：私服又称局域网，b3：其他公共仓库)
当maven根据坐标寻找构件的时候，首先查看本地仓库，如果存在此构件就直接使用，不存在就会去远程仓库寻找然后下载到本地仓库。
<project> ... <repositories> <repository> <id>jboss</id> <name>JBoss Repository</name> <url>http://repository.jboss.com/maven2/</url> <releases> //是否允许下载发布版构件 <enabled>true</enabled> </releases> </repository> <snapshots> //是否允许下载快照版构件 <enabled>false</enabled> <updatePolicy>daily</updatePolicy> <checksumPolicy>ignore</checksumPolicy> </snapshots> <layout>default</layout> </repositories> ... </project>
快照版本：A B项目同时进行开发，B项目依赖A项目，当A项目有变动时就可以发布个快照版本供B项目使用其最新的功能，maven会自动从仓库中检查A的最新快照。
镜像：如果仓库X能提供仓库Y存储的所有内容，那么就可以认为仓库X是Y的一个镜像。常结合私服一起使用。
<mirrors> <mirror> <id>mirrorId</id> <mirrorOf>repositoryId</mirrorOf> <name>Human Readable Name for this Mirror.</name> <url>http://my.repository.com/repo/path</url> </mirror> </mirrors>
4、生命周期
maven分为三种生命周期，分别是clean、default、site
clean：清理项目
default：构建项目
site：建立项目站点
每种生命周期都包含一些阶段，后面的阶段依赖前面的阶段，如果执行一个生命周期中的某一阶段，那么这一阶段前面的阶段都会执行。
default阶段包含以下阶段
validate
initialize
...
process-sources：处理项目资源文件src/main/resources
compile：编译项目主代码
...
test：测试代码
...
package
...
install
deploy:将项目复制到远程仓库 ，供其他开发人员和maven项目使用
这下应该清楚了为什么执行mvn test命令后项目的主代码也编译了。
从命令行执行maven任务实际上就是调用maven的生命周期阶段，各生命周期之间是相互独立的。
mvn clean install: 该命令调用clean周期的clean阶段和default周期的install阶段，这同一生命周期内两个阶段之前的阶段都会执行。