这篇文章对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阶段,这同一生命周期内两个阶段之前的阶段都会执行。