- 构建项目(Builds)
- 文档编制(Documentation)
- 报告(Reporting)
- 依赖管理(Dependencies)
- 配置管理(SCMs)
- 发布管理(Releases)
上例中我们声明了一个对junit的依赖,它的groupId是junit, artifactId是junit, version是4.8。这一组GAV构成了一个Maven坐标,基于此,Maven就能在本地或者远程仓库中找到对应的junit-4.8.jar文件
5. Maven如何控制依赖包的版本?
来一个例子:
<dependencies>
<dependency>
<groupId>org.spring.framework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.spring.framework</groupId>
<artifactId>spring-beans</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.spring.framework</groupId>
<artifactId>spring-web</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.spring.framework</groupId>
<artifactId>spring-mock</artifactId>
<version>${spring.version}</version>
</dependency>
</dependencies>
<properties>
<spring.version>2.5</spring.version>
</properties>
当需要升级spring的时候,只要更改一个地方便可,而且,你现在能很高的保证所有的spring依赖包都是同一个版本。
6. 依赖范围(scope)
再来几个例子:
1)
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8</version>
<scope>test</scope>
</dependency>
将依赖范围设置成test,junit对于主源码classpath不可用,对于测试源码classpath可用,不会被打包。
2)
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.4</version>
<scope>provided</scope>
</dependency>
将依赖范围设置成provided,就意味着该依赖对于主源码classpath,以及测试classpath可用,但不会被打包。这正是servlet-api所需要的。
总结一下各个依赖范围:
compile
默认的scope,表示 dependency 都可以在生命周期中使用。而且,这些dependencies 会传递到依赖的项目中。
provided
跟compile相似,但是表明了dependency 由JDK或者容器提供,例如Servlet AP和一些Java EE APIs。这个scope 只能作用在编译和测试时,同时没有传递性。
runtime
表示dependency不作用在编译时,但会作用在运行和测试时
test
表示dependency作用在测试时,不作用在运行时。
system
跟provided 相似,但是在系统中要以外部JAR包的形式提供,maven不会在repository查找它。例如:
import(Maven 2.0.9 之后新增)
它只使用在<dependencyManagement>中,表示从其它的pom中导入dependency的配置。
二,Maven的构建生命周期
国际惯例先概述下:
Maven强大的一个重要的原因是它有一个十分完善的生命周期模型(lifecycle),这个生命周期可以从两方面来理解,第一,顾名思义,运行Maven的每个步骤都由它来定义的,这种预定义的默认行为使得我们使用Maven变得简单,相比而言,Ant的每个步骤都要你手工去定义。第二,这个模型是一种标准,在不同的项目中,使用Maven的接口是一样的,这样就不用去仔细理解每个项目的构建了,一般情况下,mvn clean install这样的命令是通用的。1. 三套相互独立的生命周期
- Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
- Default Lifecycle 构建的核心部分,编译,测试,打包,部署等等。
- Site Lifecycle 生成项目报告,站点,发布站点。
2. Default 生命周期阶段描述
- validate 验证项目是否正确,以及所有为了完整构建必要的信息是否可用
- compile 编译项目的源代码
- test 使用合适的单元测试框架运行测试。这些测试应该不需要代码被打包或发布
- package 将编译好的代码打包成可分发的格式,如JAR,WAR,或者EAR
- integration-test 如果有必要的话,处理包并发布至集成测试可以运行的环境
- verify 执行所有检查,验证包是有效的,符合质量规范
- install 安装包至本地仓库,以备本地的其它项目作为依赖使用
- deploy 复制最终的包至远程仓库,共享给其它开发人员和项目(通常和一次正式的发布相关)
3. pom.xml详解<project > :文件的根节点 .
<modelversion > : pom.xml使用的对象模型版本 .
<groupId > :创建项目的组织或团体的唯一 Id.
<artifactId > :项目的唯一 Id, 可视为项目名 .
<packaging > :打包类型,一般有JAR,WAR,EAR 等
<version > :产品的版本号 .
<name > :项目的显示名,常用于 Maven 生成的文档。
<url > :组织的站点,常用于 Maven 生成的文档。
<description > :项目描述,常用于 Maven 生成的文档。<dependencies>:构件依赖<parent>:模型继承<dependencyManagement>:依赖管理<reporting>:创建报告<build>:构建<repositories>:引用第三方仓库<licenses>:许可4. Maven的插件1) 编译插件
2) 测试报告插件
3) 测试覆盖率插件