Maven

之前学过的技术，如控制层、业务逻辑层和持久层的那些技术已经可以做一个完整的项目了，为什么还需要maven?

之前学过技术存在的问题：
(1)一个项目都在一个工程里面
    如果项目十分庞大的时候就不适合用PACKAGE来划分模块，最好是一个模块就是一个工程，这样利于分工协作，借助于maven就可以将一个项目分为多个工程。

(2)项目中需要的jar包必须手动复制，粘贴到WEB-INF/BIN目录下面
这样带来的问题是：同样的jar包重复出现在不同的项目工程里面，一方面浪费存储空间，另外也让工程比较臃肿。
借助maven，可以将jar包仅仅放在仓库里面，有需要使用的工程就引用这个jar包，并不需要真正地将jar包复制过来。

(3)jar包需要别人替我们准备好或去官网下载
比较难找到我们需要的jar包，借助于maven可以以一种规范的方式下载jar包，因为所有知名的框架或第三方工具的jar包都按照
统一的标准存在了maven仓库里面，我们可以直接引用。

(4)一个jar包依赖其他的jar包需要自己手动加入到项目里面
之前我们需要记住某某jar包依赖了某某jar包，需要人为导入被依赖的jar包，这样容易出错
maven会将被依赖的jar包导入进去，不需要程序员做。

构建的概念：

构建的概念：以Java源文件、框架配置文件、JSP\HTML和图片等资源为原材料，去生成一个可以运行的项目的过程。
编译：Jana源文件（User.java）->编译->Class字节码（User.class）->交给JVM去执行
部署：一个BS项目最终运行的并不是动态web工程本身，而是这个动态web工程编译的结果
类似于：  生的鸡蛋 ->处理->熟的鸡蛋
                 动态web工程 ->编译、部署->编译的结果

TIPS:运行时环境，如JRE system library 和Apache Tomcat v6.0 这两个，其实是一组jar包的引用并没有将jar包本身复制到工程里面，所以不是目录。

什么是构建？

（1）纯java代码

构建并不是创建，.java拓展名的源文件需要编译成.class字节码文件才能执行。所以任何java代码想要执行的话就必须经过编译得到对应的.class文件。

（2）web工程

当我们需要通过浏览器来访问java程序时就必须将包含java程序的web工程编译的结果拿到服务器上指定的目录下，并启动服务器才行，这个拿的过程称为部署。

（3）实际的项目

在实际的项目里面整合第三方框架，web工程除了java工程和jsp页面、图片等静态资源之外，还包括第三方框架的jar包以及各种各样的配置文件。所有这些资源都必须按照正确的目录结构部署到服务器上面，项目才可以运行。

所以综上所述：构建就是以我们编写的java代码、框架配置文件、国际化等资源文件、JSP页面和图片等静态资源作为原材料，去生产一个可以运行的项目的过程。

构建过程中的各个环节：

（1）清理：将之前的.class文件字节码删除，为下一次编译zuo

（2）编译：将Java源程序编译成class文件

（3）测试：自动测试，自动调用junit程序

（4）报告：测试程序执行的结果

（5）打包：动态web工程打war包，Java工程打jar包

（6）安装：将打包得到的文件复制到“仓库”中指定的位置

（7）部署：将动态web工程生成的war包复制到远程maven私服仓库，也有的是将Java工程打的jar包复制到远程maven私服仓库里面。

常用的maven命令：

执行与构建过程相关的maven命令，必须进入pom.xml所在的目录，与构建过程相关如编译、测试、打包......

常用命令：

(1) mvn clean: 清理

(2) mvn complice: 编译主程序

(3) mvn test-complice: 编译测试用例

(4) mvn test: 执行测试

(5) mvn package: 打包

POM：Project Object Model 项目对象模型，pom.xml对于maven工程是核心的配置文件，与构建过程相关的一切设置都在这个文件中进行配置。

Maven的坐标：使用下面三个向量在仓库中定位一个maven工程，

(1) groupid：公司或组织域名倒序+项目名

(2) artifactid：模块名

(3) version：版本号

<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>1.6.5-SNAPSHOT</version>

maven仓库的概念：

（1）本地仓库：当前电脑上部署的仓库目录，为当前电脑上面所有的maven工程服务

（2）远程仓库：

1）私服: 搭建在局域网环境中，为局域网范围内所有的maven工程服务

2）中央仓库：架设在internet上，为全世界所有的maven工程服务

3）中央镜像仓库：为了分担中央仓库的流量，提升用户访问速度

仓库里面保存的内容：maven工程

（1）maven自身所需要的插件（2）第三方框架或工具的jar包（3）我们自己开发的maven工程

依赖：

（1）maven解析依赖信息时会到本地仓库里面查找被依赖的jar包，如果找不到就会报错。对于我们自己开发的maven工程，使用mvn install命令安装后就可以将工程的jar包存到仓库对应的地方。

（2）依赖的范围

1）complice范围依赖

对主程序是否有效：有效

对测试程序是否有效：有效

是否参与打包：参与

2）test范围依赖：         

对主程序是否有效：无效

对测试程序是否有效：有效

是否参与打包：不参与

complice范围依赖与test范围依赖的对比：

3）provide范围依赖：

对主程序是否有效：有效

对测试程序是否有效：有效

是否参与打包：不参与

complice范围依赖与provide范围依赖的对比：complice范围依赖一般是我们自己写的程序所以必须参与部署和打包等过程，provide范围依赖一般是servlet的jar包，不需要参与部署和运行等过程，因为servlet容器里面本来就有，强行部署可能会有冲突。

  

 13、生命周期

（1）各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。

（2）maven核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务都是由插件来完成的。

（3）maven核心程序为了更好地实现自动化构建，按照这一特点执行生命周期中的各个阶段：不论现在要执行生命周期的哪一个阶段，都是从这个生命周期最初的位置开始执行的。如执行install命令会从清理--编译--打包---安装这样执行的。

（4）插件和目标

1）生命周期的各个阶段仅仅定义了要执行的任务是什么？

2）各个阶段和插件的目标是对应的

3）相似的目标由特定的插件来完成

如下面表格里面所示，生命周期阶段是complice，插件目标也是complice，插件用的是maven-compiler-plugin

 14、依赖（高级）

（1）依赖的传递性，如HelloFriend工程依赖了Hello工程，如果Hello工程又依赖了springcore，这样HelloFriend工程也会依赖springcore的jar包，这就是依赖的传递性。

1）好处：可以传递的依赖不必在每个模块工程中都重复声明，在最下面的工程中依赖一次即可

2）缺点：非complice范围的依赖不能传递，所以在各个工程模块中，如果有需要就得重复声明。

（2）依赖的排除

<exclusions>

                <exclusion>

                        <groupId></groupId>

                        <artifactId></artifactId>

                </exclusion>

</exclusions>

(3)依赖的原则

 作用：解决模块工程之间的jar包冲突问题

情景设定1：在依赖传递时验证路径最短者优先原则，如上图所示MakeFriend依赖了HelloFriend和Hello,HelloFriend依赖了log4j 1.1.14,Hello依赖了log4j 1.1.17.最终MakeFriend依赖了log4j 1.1.14，因为HelloFriend距离MakeFriend近。

情景设定2：在依赖传递时验证路径相同先声明者优先，当HelloFriend和Hello距离MakeFriend距离一样的时候，看MakeFriend的pom文件先依赖的是Hello还是HelloFriend，先依赖的是谁就依赖谁的log4j。

(4)统一依赖的版本号

这里对spring各个jar包的依赖版本都是4.0.0，如果需要统一升级为4.1.1的话怎么办？

 建议使用配置方式，

1）使用propertities标签内使用自定义标签统一声明版本号，如4.0.0.RELEASE

2）在需要统一版本的位置使用${自定义标签名}引用声明的版本号,如${atguigu.spring.version}

 3)其实使用propertities标签配合自定义标签声明数据的配置并不只是只能用于声明依赖的版本号，任何需要统一的配置都可以这样写

（5）MAVEN继承

1）现状：

Hello依赖的junit是4.0版本；HelloFriend依赖的junit是4.1版本；MakeFriends依赖的是junit 4.2版本。由于test范围的依赖不能传递，所以分散在各个模块工程里面的junit版本很容易不一样。

2）需求：统一管理各个模块工程中对JUNIT依赖的版本。

3)解决思路：将junit依赖统一到父工程中，在子工程中声明junit依赖时不指定版本，以父工程统一的设定为准，同时也方便修改。

4）操作步骤：

[1] 创建一个MAVEN工程作为父工程，注意打包方式为pom

[2] 在子工程中声明对父工程的引用

[3] 将子工程中的坐标与父工程坐标中重复的内容删除

[4] 在父工程中统一junit版本

[5]在子工程中删除junit依赖的版本号部分

注意：配置继承后，执行安装命令时要先安装父工程。

（6）maven聚合

1）作用：一键安装各个模块的工程

2）配置方式：在一个总的聚合工程中配置各个曾经参与聚合的模块

 用<modules> </modules>来指定，在这个聚合工程的pom.xml文件上面点击maven install，这样就会将上面几个modules全部打包到仓库里面，这样就实现了一键安装各个模块的工程。