构件工具Maven----坐标、依赖、仓库、生命周期的简单学习

这篇文章对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文件中最常用到的东西了，用于把第三方的构件引入当前项目中。

<project>
...
<dependencies>
<dependency>
<groupId>org.srpingframework</groupId>
<artifactId>spring-core</artifactId>
<version>1.0</version>　　//以上这三个标签确定依赖的坐标以便寻找构件
<scope>compile</scope>　　//依赖的范围
<optional>true</optional> //标记依赖是否可选
<exclusions>　　　　　　　　//排除传递性依赖
<exclusion>
...
</exclusion>
<exclusions>
</dependency>
</dependencies>
</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阶段，这同一生命周期内两个阶段之前的阶段都会执行。