maven

maven解决什么问题？

Maven 可以统一管理所有的依赖 jar，甚至是不同的版本。
随着依赖的增多，版本不一致、版本冲突、依赖臃肿等问题都会接踵而来。手工解决这些问题是十分枯燥的，幸运的是 Maven 提供了一个优秀的解决方案，它通过一个坐标系统准确地定位每一个构件（artifact），也就是通过一组坐标 Maven 能够找到任何一个 Java 类库（如 jar 文件）。

maven的生命周期

名称	说明
validate	验证项目结构是否正常，必要的配置文件是否存在
initialize	做构建前的初始化操作，比如初始化参数、创建必要的目录等
generate-sources	产生在编译过程中需要的源代码
process-sources	处理源代码，比如过滤值
generate-resources	产生主代码中的资源在 classpath 中的包
process-resources	将资源文件复制到 classpath 的对应包中
compile	编译项目中的源代码
process-classes	产生编译过程中生成的文件
generate-test-sources	产生编译过程中测试相关的代码
process-test-sources	处理测试代码
generate-test-resources	产生测试中资源在 classpath 中的包
process-test-resources	将测试资源复制到 classpath 中
test-compile	编译测试代码
process-test-classes	产生编译测试代码过程的文件
test	运行测试案例
prepare-package	处理打包前需要初始化的准备工作
package	将编译后的 class 和资源打包成压缩文件，比如 rar
pre-integration-test	做好集成测试前的准备工作，比如集成环境的参数设置
integration-test	集成测试
post-integration-test	完成集成测试后的收尾工作，比如清理集成环境的值
verify	检测测试后的包是否完好
install	将打包的组件以构件的形式，安装到本地依赖仓库中，以便共享给本地的其他项目
deploy	运行集成和发布环境，将测试后的最终包以构件的方式发布到远程仓库中，方便所有程序员共享

maven依赖范围

1）compile
编译依赖范围。如果在配置的时候没有指定，就默认使用这个范围。使用该范围的依赖，对编译、测试、运行三种 classpath 都有效。
2）test
测试依赖范围。使用该范围的依赖只对测试 classpath 有效，在编译主代码或运行项目的时候，这种依赖是无效的。
3）provided
已提供依赖范围。使用此范围的依赖，只在编译和测试 classpath 的时候有效，运行项目的时候是无效的。比如 Web 应用中的 servlet-api，编译和测试的时候就需要该依赖，运行的时候，因为容器中自带了 servlet-api，就没必要使用了。如果使用了，反而有可能出现版本不一致的冲突。
4）runtime
运行时依赖范围。使用该范围的依赖，只对测试和运行的 classpath 有效，但在编译主代码时是无效的。比如 JDBC 驱动实现类，就需要在运行测试和运行主代码时候使用，编译的时候，只需 JDBC 接口就行。
5）system
系统依赖范围。该范围与 classpath 的关系，同 provided 一样。但是，使用 system 访问时，必须通过 systemPath 元素指定依赖文件的路径。因为该依赖不是通过 Maven 仓库解析的，建议谨慎使用。
6）import
导入依赖范围。该依赖范围不会对三种 classpath 产生实际的影响。它的作用是将其他模块定义好的 dependencyManagement 导入当前 Maven 项目 pom 的 dependencyManagement 中。比如有个 SpringPOM Maven 工程，它的 pom 中的 dependencyManagement 配置如下：

<dependency>
    <groupId>xxx</groupId>
    <artifactId>xxx</artifactId>
    <version>xx</version>
    <scope>system</scope>
    <systemPath>e:/xxxx/xxx/xx.jar</systemPath>
</dependency>

注：以上来源与网络