Maven学习随记

慕课网视频教程：http://www.imooc.com/learn/443

====Maven是什么

Maven是基于项目对象模型（POM），可以通过一小段描述信息来管理项目的构建、报告和文档的软件项目管理工具。简单的来说，Maven可以帮我们来管理项目。

====下载Maven

官网：http://maven.apache.org/

====配置环境变量

M2_HOME=C:\Program Files\apache-maven-3.3.3

然后将M2_HOME加入到Path中。下命令行窗口输入mvn -v时，如果可以正确显示Maven信息则表示配置成功。

====Maven的目录结构

src

--main

--java

-package

--test

---java

--package

--resources

====第一个Maven案例HelloWorld

（1）编写Java代码

（2）编写Junit测试代码

（3）配置文件

*参考博客：http://nomandia.iteye.com/blog/380010

我们可以选择从Struts的官方包中寻找一个参考pom.xml文件。

Struts下载官网：http://struts.apache.org/

路径：struts-2.3.28-all\struts-2.3.28\lib\struts2-core-2.3.28.jar\META-INF\maven\org.apache.struts\struts2-core\pom.xml

配置之后的pom.xml如下：

将配置完毕的pom.xml文件放到工程的跟目录下面。

使用命令窗口进入到项目目录，使用mvn compile命令进行代码编译。

编译成功之后，会提示BUILD SUCCESS。

*第一次运行mvn compile命令时，会下载很多插件。

然后，使用命令mvn test运行一下我们的测试用例。

运行mvn package命令来将代码打包。

====常用的构建命令介绍

参考博客：http://www.cnblogs.com/phoebus0501/archive/2011/05/10/2042511.html

（1）创建Maven的普通java项目：
mvn archetype:create
-DgroupId=packageName
-DartifactId=projectName
（2）创建Maven的Web项目：
mvn archetype:create
-DgroupId=packageName
-DartifactId=webappName
-DarchetypeArtifactId=maven-archetype-webapp
（3）编译源代码： mvn compile
（4）编译测试代码：mvn test-compile
（5）运行测试：mvn test
（6）产生site：mvn site
（7）打包：mvn package
（8）在本地Repository中安装jar：mvn install
（9）清除产生的项目：mvn clean
（10）生成eclipse项目：mvn eclipse:eclipse
（11）生成idea项目：mvn idea:idea
（12）组合使用goal命令，如只打包不测试：mvn -Dtest package
（13）编译测试的内容：mvn test-compile
（14）只打jar包: mvn jar:jar
（15）只测试而不编译，也不测试编译：mvn test -skipping compile -skipping test-compile
( -skipping 的灵活运用，当然也可以用于其他组合命令)
（16）清除eclipse的一些系统设置:mvn eclipse:clean
（17）显示版本信息:mvn -version/-v
（18）删除再编译：mvn clean install

====自动创建目录骨架

archetype插件，用于创建符合maven规定的目录骨架。

使用命令mvn archetype:generate来创建一个工程，

第一次使用该命令时会下载很多插件，比较耗费时间。

下载完毕之后，会提示输入一下信息：

groupId、artifactId、version、package

生成之后的工程路径如下：

====Maven中的坐标和仓库

（1）坐标

在Maven世界中，任何一个依赖、插件等，都可以称之为构件。

所有构件都通过坐标作为其唯一的标识。

（2）仓库

是用来管理项目的依赖。分为两种：本地仓库和远程仓库

如果本地仓库中找不到我们的构件时，会去Maven的全球仓库中查找并下载到本地。

全球仓库地址：http://search.maven.org/

（3）镜像仓库

Maven的中央仓库服务器都是位于国外的，因为某种原因导致我们无法访问外网，可以使用国内的Maven镜像仓库。

apache-maven-3.3.3\conf\settings.xml（146行左右）

（4）更改仓库位置

修改apache-maven-3.3.3\conf\settings.xml文件中的下面配置。

<localRepository>/path/to/local/repo</localRepository>

====maven的声明周期和插件

--完整的项目构建过程包括：

清理、编译、测试、打包、集成测试、验证、部署

--Maven生命周期包括：

参考博客：http://juvenshun.iteye.com/blog/213959

clean　　在进行真正的构建之前进行一些清理工作

default　构建的核心部分，编译，测试，打包，部署等等

site　　  生成项目报告，站点，发布站点

它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。

当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期

记住，运行任何一个阶段的时候，它前面的所有阶段都会被运行，

这也就是为什么我们运行mvn install 的时候，代码会被编译，测试，打包。

====依赖范围

Maven的坐标为各种构件引入了秩序，任何一个构件都必须明确的定义自己的坐标，maven的坐标包括如下的元素：

groupId: 定义当前Maven项目隶属的实际项目

artifactId: 该元素定义实际项目中的一个Maven项目或模块

version: 该元素定义Maven项目当前所处的版本

packaging: 该元素定义Maven项目的打包方式

classifier: 该元素用来帮助定义构建输出的一些附属构件

注：groupId、artifactId、version、packaging是必须定义的，classifier是不能被直接定义的，因为附属构件不是项目直接默认生成的，而是由附加的插件帮助生成的。

元素详解：

根元素project下的dependencies元素详解：

dependencies可以包含一个或者多个dependency元素，以声明一个或多个项目依赖, 其包含的元素：

groupId、artifactId、version：依赖的基本坐标，对于任何一个依赖来说，基本的坐标是最重要的，Maven是根据坐标来找到需要的依赖

type: 依赖的类型

scope: 依赖的范围

optional: 标记依赖是否可选(参见可选性依赖)

exclusions: 用来排除传递性依赖(参见依赖的传递性)

依赖范围详解：

Maven在编译项目主代码的时候需要使用一套classpath

Maven在编译和执行测试的时候会使用另外一套classpath

Maven在实际运行项目的时候又会使用一套classpath

依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系

Maven的6种依赖范围：

compile: 编译依赖范围(默认)，对于编译、测试、运行三种classpath都有效

test: 测试依赖范围， 只对测试classpath有效。典型范例：Junit

provided: 已提供依赖范围 对于编译和测试classpath有效，但在运行时无效。典型范例：servlet-api

runtime: 运行时依赖范围 对于测试和运行classpath有效，但在对编译主代码时无效。典型范例：JDBC

system: 系统依赖范围

import: (maven2.0.9及以上): 导入依赖范围，它不会对三种实际的classpath产生影响

依赖范围(Scope)	对于编译classpath有效	对于测试classpath有效	对于运行时classpath有效	例子
compile	Y	Y	Y	spring-core
test		Y		junit
provided	Y	Y		servlet-api
runtime		Y	Y	JDBC驱动实现
system	Y	Y		本地的，Maven仓库之外的类库文件

了解了依赖的基本元素和依赖范围之后，我们会发现在我们项目中经常会出现一些默认的配置问题，导致编译和运行失败的情况，现在让我们来学习如何解决这些问题，首先要了解一下依赖的传递性

传递性依赖和依赖范围

简单的说，一般项目中出现问题多数是因为重复的引用或者引用了较低版本的依赖，或者是他们的依赖范围发生了变化。

举个例子来理解传递性依赖：

我们创建了一个Maven Project-----learnDependency，然后我们引入了spring-core这个依赖，然后我们打开spring-core的pom.xml发现，spring-core也有自己的依赖：commons-logging，而且该依赖没有声明依赖范围，那么默认的就是compile，所以这时我们就可以说：commons-logging也是learnDependency的一个依赖，这时我们就将这种依赖称之为传递性依赖，commons-logging是learnDependency的一个传递性依赖。有了传递性依赖，我们就可以在使用的时候不去考虑我们引入的依赖到底是否需要其它依赖，和是否引入多余的依赖，Maven 会解析各个直接依赖的pom，将必要的间接依赖引入到项目中。

细说传递性依赖

假设：A依赖于B，B依赖于C，那么我们就说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。

因为依赖是有依赖范围的，那么对于这种传递性依赖Maven又是如何界定其依赖范围的呢？

当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；

当第二直接依赖的范围是test的时候，依赖不会得以传递

当第二直接依赖的范围是provided的时候，只传递第一依赖范围也为provided的依赖，且传递性依赖的范围同样是provided；

当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile除外，此时传递性依赖范围为runtime

	compile	test	provided	runtime
compile	compile			runtime
test	test			test
provided	provided		provided	provided
runtime	runtime			runtime

左侧第一列表示第一直接依赖范围，最上面一行表示第二直接依赖

在我们了解了Maven强大的依赖机制之后，我们开始解决问题：

常见问题一：依赖的重复引入

之前说过Maven可以有效的解决依赖的重复引入问题，但是为什么我们在项目还会出现这类问题呢？先让我们来看一下Maven是如何处理重复引入问题的：

情景一：我们在项目中分别引入了2个依赖A和B，A又依赖的C，C又依赖了D，B也依赖了D，但是这个时候C依赖的D和B依赖的D的版本是不同的：

项目----A---C----D

项目----B---D

也就是说，当前项目引入了2次D依赖，那么这时，Maven将采用第一原则：路径最近原则

情景二：我们在项目中分别引入了2个依赖A和B，而A和B又都引入了C，但是，此时A依赖的C和B依赖的C版本是不一致的，那么这个时候Maven如何处理呢？

这时，第一原则已经不起作用了，

在Maven2.0.8及之前的版本中  和 Maven2.0.9之后的版本Maven对于这种情况的处理方式是不一致的

确切的说：

在Maven2.0.8及之前的版本中Maven究竟会解析哪个版本的依赖，这是不确定的

在Maven2.0.9之后的版本中，制定了第二原则：第一声明者优先

就是说，它取决于在POM中依赖声明的顺序

这个问题就说明了，为什么我们常常遇到的可以正常运行的项目，然后我们增加了一个看似无关的依赖，然后项目就出现了错误，就是这个传递性依赖搞的鬼！

还要补充说明的一种情况是可选依赖

为什么会有可选依赖呢？是因为某一个项目实现了多个特性，但是我们在面向对象的设计中，有一个原则叫：单一职责性原则，就是强调在一个类只有一项职责，而不是糅合了太多的功能，所以一般这种可选依赖很少会出现。

常见问题二：默认引入的依赖----第二直接依赖的版本过低或者依赖了不稳定的快照

这个问题我们在开发中也经常遇到，在某个第二直接依赖中引入了1.0版本，但是我们现在想使用2.0版本，这时我们要如何解决？

引入一个名词：排除依赖，也可以叫替换依赖

想实现依赖排除，然后替换成自己想要的依赖，这时我们要用到的一个配置是<exclusions>和<exclusion>，我们可以使用这一元素声明排除依赖，然后显示的声明我们想要的依赖，在<exclusions>中可以声明一个或多个<exclusion>来排除一个或多个传递性依赖。

注：声明<exclusion>的时候只需要声明groupId和artifactId就能唯一定位依赖图中的某个依赖。

A ------->  B ------×----C(version1.0)

|

C(version2.0)

常见问题三：解决重复的配置

我们在开发中也经常遇到这样的情况，比如在使用spring framework的时候，他们都是来自于同一个项目的不同模块，因此这些依赖的版本都是相同的，而且在将来升级的时候，这些版本也会一起被升级，这时Maven又提供了一种解决方案------使用properties元素定义Maven属性，然后引用。

示例：

1. <properties>
2. <springframework.version>2.5.6</springframework.version>
3. </properties>

这个时候我们就可以在声明依赖的时候使用${springframework.version}来替换具体的版本号

1. <dependency>
2. <groupId>org.springframework</groupId>
3. <artifactId>spring-context-support</artifactId>
4. <version>${springframework.version}</version>
5. </dependency>

如何正确的优化依赖

首先我们必须要对maven的依赖处理方式了然于胸，然后我们就可以去除多余的依赖，显示的声明必要的依赖，保证每个构件都只有唯一的版本在依赖中存在

使用命令来查看当前项目的已解析依赖：

mvn dependency : list

经过Maven解析之后，就会构成一个依赖树

也可以使用命令查看当前项目的依赖树：

mvn dependency : tree

使用命令分析当前当前项目的依赖：

mvn dependency : analyze

该命令执行结果的两个重要部分：

Used undeclared dependencies: 表示项目中使用到的，但是没有显示声明的依赖

Unused declared dependencies: 表示项目中未使用的，但显示声明的依赖

注：dependency : analyze只会分析编译主代码和测试代码需要用到的依赖，一些执行测试和运行时需要的依赖它无法发现。