maven：是一个跨平台的项目管理工具，主要服务于Java平台的项目构建、依赖管理和项目信息管理。项目构建：通过插件帮你完成项目的清理、编译、测试、打包、部署。依赖管理：通过坐标从maven仓库导入java类库（jar文件）项目信息管理：项目描述、开发者列表、版本控制系统地址、许可证、缺陷管理系统地址等。

下载页面：http://maven.apache.org/downl...下载解压即可。在安装 Maven 之前，需确保安装JDK,可通过 java -version 命令查看环境变量配置：1） M2_HOME = maven的bin目录所在路径(不包含/bin)2） Path 添加 %M2_HOME%/binmaven升级：下载新版本Maven解压，修改M2_HOME路径即可Linux 可通过符号链接简化 Maven升级

mvn help:system 该命令会打印出所有的Java系统属性和环境变量

在用户目录下可以发现.m2文件夹。默认情况下，.m2文件下只放置了Maven本地仓库repository,不过大多数Maven用户需要复制 settings.xml 到此目录下作为用户配置文件。

IDE使用Maven需要安装Maven插件,如Eclipse的m2eclipse插件，NetBeans的Maven插件

默认情况下Maven项目目录

项目编译命令 mvn clean compile此命令主要执行了三个插件以及插件目标

添加POM依赖，导入Junit jar包

一个典型测试单元需具备三步骤：1 准备测试类及数据 2 执行要测试的方法 3 检查结果在测试包中创建测试类（类名不要为Test）,编写测试方法（void无返回值 @Test注释）,

项目测试命令：mvn clean test此命令主要执行了五个插件以及插件目标

mvn clean package该命令会在编译、测试后执行 jar：jarjar:jar任务负责打包，jar插件的jar项目在tartget目录将主代码打包成jar包，根据artifact-version.jar（项目名-版本号.jar）命名,也可通过标签中的子标签来自定义

mvn clean install 其他Maven项目依赖此项目时，需将jar包安装到Maven本地仓库中该命令会在编译、测试、打包后执行install:installinstall:install任务将jar包安装到本地仓库repository下,规则为groupIdartifactIdversionartifactId-version.jar

可执行jar包需要设置 META-INF/MANIFEST.MF 文件中编辑 Main-Class 一行。也可通过配置maven-shade-plugin 或 maven-jar-plugin 等插件实现

在项目的根目录中放置pom.xml,在src/main/java中放置项目的主代码，在src/test/java中放置项目的测试代码。我们称这些基本的目录结构和pom.xml文件内容为项目骨架，Archetype可以帮助我们快速勾勒出项目骨架。

运行插件maven-archetype-plugin生成项目骨架：格式：mvn groupId:artifactId:version:goalmvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-5:generate简化格式：mvn archetype:generate (maven2中是不安全，会自动下载最新的版本，可能得到不稳定的SNAPSHOT版本)

执行插件之后会列出很多可用的Archetype列表,每一个Archetype前面都会对应有一个编号，同时命令行会提示一个默认的编号，其对应的Archetype为maven-archetype-quickstart,直接回车以选择该Archetype，或输入指定编号回车紧接着会Maven会提示输入要创建项目的groupId、artifactId、version以及包名package,确认后即可生成一个maven项目。

Maven定义了一组规则，世界上任何一个构件都可以使用Maven坐标唯一标识，Maven坐标的元素包括 groupId、artifactId、version、packaging、classifier中央仓库：Maven通过坐标从中央仓库寻找相应的构件供我们使用。

上述5个元素中，groupId、artifactId、version是必须定义的，packaging是可选的（默认为jar），而classifier是不能直接定义的。项目构件的文件名规则：artifactId-version[-classifier].packagingmaven仓库的布局也是基于maven坐标的

根元素project下的dependencies可以包含多个dependency元素，以声明一个或多个项目依赖

首先,Maven在编译项目主代码时需要使用一套classpath（编译classpath）；其次，Maven在编译和执行测试的时候会使用另外一套classpath(测试classpath)；最后，实际运行Maven项目的时候，又会使用另外一套classpath（运行classpath）。依赖范围：maven需要使用三套classpath，控制依赖与三种classpath(编译classpath、测试classpath、运行classpath)的关系，Maven有以下几种依赖范围。

假设：A->B->C当项目A依赖于B包，而B包又依赖于C包，故需要引入C包。使用Maven只需要引入B包即可，C包由Maven通过传递性依赖引入。Maven通过传递性依赖机制，解析各个直接依赖的POM,将那些必要的间接依赖，以传递性依赖的形式引入到当前的项目中。

假设：A->B->CA依赖B -> 第一直接依赖 依赖范围B依赖C -> 第二直接依赖 依赖范围A依赖C -> 传递性依赖 依赖范围 由第一直接依赖和第二直接依赖决定，如下图总结：第二直接依赖范围是compile，传递性依赖范围与第一直接依赖范围一致；第二直接依赖范围是test,依赖不得以传递；第二直接依赖范围是provided,只第一直接依赖范围也为provided时，传递性范围同样为provided;第二直接依赖范围是runtime,除第一直接依赖范围为compile时为runtime,传递性依赖范围与第一直接依赖范围一致。

假设：A->B->C-X(1.0)    A->D->X(2.0)传递性依赖机制引入不通版本的X时，发生依赖重复，Maven遵循的第一原则：路径最近者优先。该例中X(1.0)路径长度为3，X(2.0)路径长度为2。因此X(2.0)会被解析使用当路径长度相同时，Maven(2.0.9之后)定义第二原则：第一声明者优先。

假设：A->B , B->X(可选) , B->Y(可选)如果所有这个三个依赖的范围都是compile，那么X,Y就是A的compile范围传递性依赖，但是，由于X,Y是可选依赖，依赖将不得以传递。

可选依赖的使用场景：项目B具有两个特性，特性一依赖于X，特性二依赖于Y，并且这两个特性是互斥的，用户无法同时使用。比如B是一个持久层隔离工具包，它支持多个数据库，包括MySql（假设驱动依赖X）、Oracle(假设驱动依赖Y)，在构建项目B时，需要引入这两种数据库的驱动程序，但在引入项目B时，只会依赖一种数据库，此时项目B构建时需声明依赖X，Y可选（true），当项目A依赖项目B时，X，Y项目依赖不会被传递，同时项目A根据实际需求，显式声明X或Y依赖(如项目使用MySql数据库时，项目A依赖项目B,同时显式声明X依赖)

说明：在理想状态下，是不应该使用可选依赖。可选依赖是基于一个项目实现多个特性，违背了面向对象设计中的单一职责性原则。

假设：A->B-X(1.0)传递性依赖会隐式地引入很多依赖，如依赖X(1.0)，这极大地简化项目依赖管理，但这种特性也会带来一些问题。例如，我需要依赖X(2.0)时，可以使用排除依赖排除X(1.0),同时显式声明X(2.0)依赖。代码中使用exclusions元素声明排除依赖，exclusions可以包含一个或多个exclusion子元素，因此可以排除一个或多个传递性依赖。注意：声明exclusion时只需要groupId和artifactId，不需要version。因为Maven解析后的依赖中，不会存在groupId和artifactId相同，而version不同的两个依赖（依赖调解特性）。

引入同一项目的不同模块时，这些依赖的版本都是相同的，如Spring Framework这里简单用到了Maven属性，首先使用properties元素声明Maven属性（定义版本），并在dependency声明中引用这个版本(${})。

了解Maven项目的依赖，去除多余的依赖，显式地声明某些必要的依赖

Maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保一个构件只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为已解析依赖。mvn dependency:list 查看已解析依赖列表及其依赖范围

在此基础上，还能进一步了解已解析依赖的信息，将直接在当前项目POM声明的依赖定义为顶层依赖，而这些顶层依赖的依赖则定义为第二层依赖，以此类推，有第三、第四层依赖。当这些依赖经解析后，就会构成一个依赖树。通过这个依赖树就能清楚得看到某个依赖是通过哪条传递路径引入的。mvn dependency:tree 查看当前项目的依赖树

mvn dependency:analyze 帮助分析当前项目的依赖通过分析依赖树，可以得到两个重要结果：1 Used undeclared dependencies:意指项目中使用到的，但是没有显式声明的依赖。（存在隐患）假设：A->B->C如果项目A->C时，并且项目A并没有显示声明C依赖时，而使用B的传递依赖C时，当升级直接依赖B，传递依赖C也可能发送变化，并且这种变化不易发现，导致当前项目出错。如接口改变，导致编译失败。因此，显式声明任何项目中直接用到的依赖。2 Unused declared dependencies:意指项目中未使用的，但显式声明的依赖。对于这一类依赖，不要简单的直接删除其声明，而是应该仔细分析，因为dependency:analyze工具只会分析编译主代码和测试代码需要用到的依赖，一些执行测试和允许时需要的依赖它就发现不了。