笔记：Maven

Maven

为什么使用Maven

1.添加第三方jar包

在今天的JavaEE开发领域，有大量的第三方框架和工具可以供我们使用。要使用这些jar包最简单的方法就是复制粘贴到WEB-INF目录下的lib目录下。但是这会导致每次创建一个新的工程就需要将jar包重复复制到lib目录下，从而造成工作区中存在大量重复的文件。
而使用Maven后每个jar包只在本地仓库中保存一份，需要jar包的工程只需要维护一个文本形式的jar包的引用——我们称之为“坐标”。不仅极大的节约了存储空间，让项目更轻巧，更避免了重复文件太多而造成的混乱。

2.解决了jar包之间的依赖关系

jar包往往不是孤立存在的，很多jar包都需要在其他jar包的支持下才能够正常工作，我们称之为jar包之间的依赖关系。最典型的例子是：commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar，如果没有IO包，FileUpload包就不能正常工作。
那么问题来了，你知道你所使用的所有jar包的依赖关系吗？当你拿到一个新的从未使用过的jar包，你如何得知他需要哪些jar包的支持呢？如果不了解这个情况，导入的jar包不够，那么现有的程序将不能正常工作。再进一步，当你的项目中需要用到上百个jar包时，你还会人为的，手工的逐一确认它们依赖的其他jar包吗？这简直是不可想象的。
而引入Maven后，Maven就可以替我们自动的将当前jar包所依赖的其他所有jar包全部导入进来，无需人工参与，节约了我们大量的时间和精力。用实际例子来说明就是：通过Maven导入commons-fileupload-1.3.jar后，commons-io-2.0.1.jar会被自动导入，程序员不必了解这个依赖关系。

3.处理jar包之间的冲突

上一点说的是jar包不足项目无法正常工作，但其实有的时候jar包多了项目仍然无法正常工作，这就是jar包之间的冲突。
举个例子：我们现在有三个工程MakeFriend、HelloFriend、和Hello。MakeFriend依赖HelloFriend，HelloFriend依赖Hello。而Hello依赖log4j.1.2.17.jar，HelloFriend依赖log4j.1.2.14.jar。如下图所示：

那么MakeFriend工程的运行时环境中该导入log4j.1.2.14.jar呢还是log4j.1.2.17.jar呢？
这样的问题一个两个还可以手工解决，但如果系统中存在几十上百的jar包，他们之间的依赖关系会非常复杂，几乎不可能手工实现依赖关系的梳理。
使用Maven就可以自动的处理jar包之间的冲突问题。因为Maven中内置了两条依赖原则：最短路径者优先和先声明者优先，上述问题MakeFriend工程会自动使用log4j.1.2.14.jar。

4.获取第三方jar包

JavaEE开发中需要使用到的jar包种类繁多，几乎每个jar包在其本身的官网上的获取方式都不尽相同。为了查找一个jar包找遍互联网，身心俱疲，没有经历过的人或许体会不到这种折磨。不仅如此，费劲心血找的jar包里有的时候并没有你需要的那个类，又或者又同名的类没有你要的方法——以不规范的方式获取的jar包也往往是不规范的。
使用Maven我们可以享受到一个完全统一规范的jar包管理体系。你只需要在你的项目中以坐标的方式依赖一个jar包，Maven就会自动从中央仓库进行下载，并同时下载这个jar包所依赖的其他jar包——规范、完整、准确！一次性解决所有问题！
Tips：在这里我们顺便说一下，统一的规范几乎可以说成是程序员的最高信仰。如果没有统一的规范，就意味着每个具体的技术都各自为政，需要以诸多不同的特殊的方式加入到项目中；好不容易加入进来还会和其他技术格格不入，最终受苦的是我们。而任何一个领域的统一规范都能够极大的降低程序员的工作难度，减少工作量。例如：USB接口可以外接各种设备，如果每个设备都有自己独特的接口，那么不仅制造商需要维护各个接口的设计方案，使用者也需要详细了解每个设备对应的接口，无疑是非常繁琐的。

5.将项目拆分成多个工程模块

随着JavaEE项目的规模越来越庞大，开发团队的规模也与日俱增。一个项目上千人的团队持续开发很多年对于JavaEE项目来说再正常不过。那么我们想象一下：几百上千的人开发的项目是同一个Web工程。那么架构师、项目经理该如何划分项目的模块、如何分工呢？这么大的项目已经不可能通过package结构来划分模块，必须将项目拆分成多个工程协同开发。多个模块工程中有的是Java工程，有的是Web工程。
那么工程拆分后又如何进行互相调用和访问呢？这就需要用到Maven的依赖管理机制。大家请看调查项目拆分的情况：

上层模块依赖下层，所以下层模块中定义的API都可以为上层所调用和访问。

6.实现项目的分布式部署

在实际生产环境中，项目规模增加到一定程度后，可能每个模块都需要运行在独立的服务器上，我们称之为分布式部署，这里同样需要用到Maven。

什么是Maven

1.自动化构建工具

1)Maven这个单词的本意是：专家，内行。读音是['meɪv(ə)n]或['mevn]，不要读作“妈文”。
2)Maven是一款自动化构建工具，专注服务于Java平台的项目构建和依赖管理。在JavaEE开发的历
史上构建工具的发展也经历了一系列的演化和变迁：
Make→Ant→Maven→Gradle→其他……

2.什么是构建

1)构建并不是创建，创建一个工程并不等于构建一个项目。要了解构建的含义我们应该由浅入深的从以下三个层面来看：
①纯Java代码
大家都知道，我们Java是一门编译型语言，.java扩展名的源文件需要编译成.class扩展名的字节码文件才能够执行。所以编写任何Java代码想要执行的话就必须经过编译得到对应的.class文件。
②Web工程
当我们需要通过浏览器访问Java程序时就必须将包含Java程序的Web工程编译的结果“拿”到服务器上的指定目录下，并启动服务器才行。这个“拿”的过程我们叫部署。
我们可以将未编译的Web工程比喻为一只生的鸡，编译好的Web工程是一只煮熟的鸡，编译部署的过程就是将鸡炖熟。
Web工程和其编译结果的目录结构对比见下图：

③实际项目
在实际项目中整合第三方框架，Web工程中除了Java程序和JSP页面、图片等静态资源之外，还包括第三方框架的jar包以及各种各样的配置文件。所有这些资源都必须按照正确的目录结构部署到服务器上，项目才可以运行。
所以综上所述：构建就是以我们编写的Java代码、框架配置文件、国际化等其他资源文件、JSP页面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程。
那么项目构建的全过程中都包含哪些环节呢？

构建环节

1)清理：删除以前的编译结果，为重新编译做好准备。
2)编译：将Java源程序编译为字节码文件。
3)测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
4)报告：在每一次测试后以标准的格式记录和展示测试结果。
5)打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对应war包。
6)安装：在Maven环境下特指将打包的结果——jar包或war包安装到本地仓库中。
7)部署：将打包的结果部署到远程仓库或将war包部署到服务器上运行。

自动化构建

Maven核心概念

1)POM
2)约定的目录结构
3)坐标
4)依赖管理
5)仓库管理
6)生命周期
7)插件和目标
8)继承
9)聚合

POM

Project Object Model：项目对象模型。将Java工程的相关信息封装为对象作为便于操作和管理的模型。Maven工程的核心配置。可以说学习Maven就是学习pom.xml文件中的配置。

约定的目录结构

现在JavaEE开发领域普遍认同的一个观点：约定>配置>编码。意思就是能用配置解决的问题就不编码，能基于约定解决的问题就不配置，而Maven正是因为指定了特定文件保存的目录才能够对我们的Java工程进行自动化构建。

坐标

Maven坐标
使用如下三个向量在Maven的仓库中唯一的确定一个Maven工程
1.groupld：公司或组织的域名倒序+当前项目名称
2.artifactld：当前版本的模块名称
3.version：当前模块版本
如何通过坐标到仓库中查找jar包
[1]将gav三个向量连起来
[2]以连起来的字符串作为目录结构到仓库中查找

依赖

配置两个maven程序
设置其中一个依赖另一个
第二个工程会到哪里去找第一个工程呢？
答案是：本地仓库。任何一个Maven工程会根据坐标到本地仓库中去查找它所依赖的jar包。如果能够找到则可以正常工作，否则就不行。

仓库

分类：本地仓库/远程仓库
[1] 私服：架设在当前局域网环境下，为当前局域网范围内的所有Maven工程服务。

[2]中央仓库：架设在Internet上，为全世界所有Maven工程服务。
[3]中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。
2)仓库中的文件
①Maven的插件
②我们自己开发的项目的模块
③第三方框架或工具的jar包
不管是什么样的jar包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查
询或依赖。

生命周期

1)什么是Maven的生命周期？
Maven生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven就可以自动化的执行构 建命令了。
Maven有三套相互独立的生命周期，分别是：
Clean Lifecycle在进行真正的构建之前进行一些清理工作。
Default Lifecycle构建的核心部分，编译，测试，打包，安装，部署等等。
Site Lifecycle生成项目报告，站点，发布站点。
再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。

每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean，这个clean是Clean生命周期的一个阶段。有Clean生命周期，也有clean阶段。

2)clean生命周期
Clean生命周期一共包含了三个阶段：
pre-clean 执行一些需要在clean之前完成的工作
clean 移除所有上一次构建生成的文件
post-clean 执行一些需要在clean之后立刻完成的工作

3)Site生命周期
pre-site 执行一些需要在生成站点文档之前完成的工作
site 生成项目的站点文档
post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
site-deploy 将生成的站点文档部署到特定的服务器上
这里经常用到的是site阶段和site-deploy阶段，用以生成和发布Maven站点，这可是Maven相当强大的功能，Manager比较喜欢，文档及统计数据自动生成，很好看。

4)Default生命周期
Default生命周期是Maven生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中。这里，只解释一些比较重要和常用的阶段：
validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件，至目标目录，准备打包。
compile 编译项目的源代码。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件，至目标测试目录。
test-compile 编译测试源代码。
process-test-classes
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package
package 接受编译好的代码，打包成可发布的格式，如JAR。
pre-integration-test
integration-test
post-integration-test
verify
install将包安装至本地仓库，以让其它项目依赖。
deploy将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。

5)生命周期与自动化构建
运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行mvn install 的时候，代码会被编译，测试，打包。这就是Maven为什么能够自动执行构建过程的各个环节的原因。此外，Maven的插件机制是完全依赖Maven的生命周期的，因此理解生命周期至关重要。

依赖

依赖的范围

compile
1.main目录下的Java代码可以访问这个范围的依赖
2.test目录下的Java代码可以访问这个范围的依赖
3.部署到Tomcat服务器运行时要放在WEB-INB的lib目录下

test
1.main目录下的Java代码不能访问这个范围的依赖
2.test目录下的Java代码可以访问这个范围的依赖
3.部署到Tomcat服务器上运行时不会放在WEB-INF的lib下
provided
main目录下的java代码可以访问到这个范围的依赖
test目录下的Java代码可以访问这个范围的依赖
部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下

依赖的传递性

当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。例如：
Maven工程 依赖范围 对A的可见性

依赖的原则

1)路径最短者优先

2)路径相同时先声明者优先

这里“声明”的先后顺序指的是dependency标签配置的先后顺序。

依赖的排除

有的时候为哦嗯确保程序可以正确的将有可能重复的间接依赖排除，如下：
假设当前工程A直接依赖ev，ev依赖com的1.1版本，那么A间接依赖com的1.1版本，但是当前A工程直接依赖com的1.2版本
这时，加入exclusions配置可以在依赖com的时候排除版本1.1的间接依赖

<!-- 依赖排除 -->
	<exclusions>
		<exclusion>
			<groupId>com</groupId>
			<artifactId>com</artifactId>
		</exclusion>
	</exclusions>

统一管理目标jar包版本

以对Spring的jar包依赖为例，Spring的每一个版本中都包含spring-core、Spring-context等jar包，我们应该导入版本一致的Spring jar包，而不是使用4.0.0的spring-core的同时使用4.1.1的spring-context

<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-core</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-context</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-jdbc</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-orm</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-web</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-webmvc</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>

这时，我们如果想将这些标签统一升级为4.1.1，如果一个一个修改，太浪费时间
我们有一个统一的方式

<propreties>
	<spring.version>4.1.1.RELEASE</spring.version>
</propreties>


......
<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-core</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-context</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-jdbc</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-orm</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-web</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-webmvc</artifactId>
			<version>${spring.version}</version>
		</dependency>

这样，只需要改一个标签就够了

继承

由于非compile范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置
如果有项目要将各个模块的junit版本统一为4.9，那么各个工程中手动修改无疑是非常不可取的，使用继承机制就可以将这样的依赖信息提取到一个父工程模块进行统一管理。

创建父工程

创建父工程和创建一般的java工程操作一直，唯一需要注意的是：打包方式设置为pom

在子工程引用父工程

<parent>
	<!-- 父工程坐标 -->
	<groupId>...</groupId>
	<artifactId>...</artifactId>
	<version>...</version>
	<!-- 从当前子工程pom文件出发，查找父工程的pom文件路径 -->
	<relativePath>从当前目录到父项目的pom.xml文件的相对路径</relativePath>
</parent>

这时子工程的<version>...</version>和<groupId>...</groupId>如果和父工程一样，可以删除

在父工程中管理依赖

将Parent项目中的dependdencies标签，用dependecyManagement标签括起来

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.9</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</dependencyManagement>

在子项目中重新指定需要的依赖，删除范围和版本号

<dependencies>
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
	</dependency>
</dependencies>

聚合

将多个工程拆分为模块后，需要手动诸葛安装到仓库后依赖才能生效，修改源码后也需要逐个手动进行clean操作。而使用了聚合之后就可以批量进行Maven工程的安装与清理

如和配置聚合

在总的聚合工程中使用modules/module标签组合，指定模块工程的相对路径即可

<modules>
	<module>../Hello</module>
	<module>../HelloFriend</module>
	<module>../MakeFriends</module>
</modules>