maven到底有什么用

maven其实有两个作用，一个是管理依赖，一个是构建项目。

首先明确传统javaWeb项目的周期

1.管理依赖

        以pom.xml文件中dependency属性管理依赖的jar包，所有需要的jar包先从本地仓库拿，获取不到再去远程仓库下载，即使jar包冲突也能在项目中有所体现，可以很直观的看到哪些jar包有冲突。

compile: 编译依赖范围(默认)。

test：测试依赖范围。在测试(编译测试程序代码)的classpath有效，在编译主代码或者运行主代码的时候都无法依赖此类依赖。典型的例子是jUnit,它只有在编译测试代码及运行测试代码的时候才有效。

provided:已提供依赖范围。在编译(编译主程序代码)和测试(编译测试程序代码)classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行的时候，由于容器已经提供，就不需要maven重复地引入一遍。打包的时候可以不用包进去，别的设施会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是打包阶段做了exclude操作。

        首先明确一点，java的项目结构中，除了我们导入的jar包，除了我们编写的代码，还有一部分结构，这部分被称为java的运行时环境。

 这也就是为什么，我们编写jsp的时候，jsp能够识别我们的<% %>命令，因为servlet-api等其它相关的jar包集成在了Apache tomcat的运行时环境里(也可以说由你的应用服务器或者servlet 容器提供)。

因此打包的时候，provided类型的jar包就将不会被一起打包到war包里，因为你肯定新的机器的运行时环境里有对应的jar包，war包到了新的机器上，一样能运行。

runtime:运行时依赖范围。在测试(编译测试程序代码)和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要jdk提供的jdbc的接口，只有在执行测试或者运行测试的时候才需要实现上述接口的jdbc的驱动。

system:系统依赖范围。在编译(编译主程序代码)、测试(编译测试程序代码)时有效，但是在运行时无效。和provided的区别是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。

例如：

<dependency>
 
<groupId>javax.sql</groupId>
 
<artifactId>jdbc-stdext</artifactId>
 
<version>2.0</version>
 
<scope>system</scope>
 
<systemPath>${java.home}/lib/rt.jar</systemPath>
 
</dependency>

import:导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。只有在dependencyManagement下才有效果。

2.构建项目

什么是构建？

以java源文件、框架配置文件、jsp、html、其它静态素材等资源为原材料，去生产一个可以运行的项目的过程。