Maven笔记

一.目前项目开发中存在的问题（why）

1.一个项目就是一个工程

如果一个项目十分庞大，就不适合使用package来划分模块，最好每个模块对应一个工程
借助于Maven就能将一个项目拆分为多个工程

2.项目中需要的jar包必须手动”复制”，”粘贴”到WEB-INF/lib目录中

带来的问题就是：同样的jar包出现在不同的工程中，一方面浪费储存空间，另外也让工程臃肿
借助Maven，可以将jar包保存在仓库中，有需要使用的工程只需要引用这个文件接口，而不需要
把jar包复制过来

3.jar包需要别人替我们准备好，或者自己去下载

不同技术的官网提供的jar包下载的形式是五花八门的，有些技术的官网就是通过Maven或SVN等
专门的工具来提供下载的

如果是一非正规的方式下载的jar包，那么其中的内容也是不规范的

借助于Maven可以以一种规范的方式下载jar包，因为所有的知名框架或第三方工具的jar包
以及按照统一的规范存放在Maven的中央仓库中

以规范的方式下载jar包，内容都是可靠的

Tips：”统一的规范”不仅是对IT开发领域非常重要，对整个人类社会都是非常重要的

4.一个jar包依赖其他jar包需要手动加入到项目中

FileUpload组件->IO组件。
如果所有的jar包之间的依赖关系都需要程序员自己非常清楚的了解，那么就会极大的
增加学习成本，Maven会自动的将被依赖的jar包导入进来

二.Maven是什么（what）

1.Maven是一款服务于java平台的自动化构建工具

Make->Ant->Maven->Gradle

2.构建

(1)概念：以”java源文件”、”框架配置文件”、”JSP”、”HTML”、”图片”等资源为原材料，去
生产一个可以运行的项目的过程（编译，部署，搭建）
(2)编译：Java源文件（user.java）->编译—>Class字节码文件（User.class）->交给JVM去执行
(3)部署：一个BS项目最终运行的并不是动态Web工程本身，而是这个动态Web工程编译的结果
动态Web工程->编译，部署->编译结果（生的鸡->屠宰，烹饪->熟的鸡）
开发过程中，所有的路径或部署的类路径都是以编译结果的目录结构为标准的
(4)构建过程的几个主要环节
①清理：删除以前的编译结果，为重新编译做好准备。
②编译：将 Java 源程序编译为字节码文件。
③测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
④报告：在每一次测试后以标准的格式记录和展示测试结果。
⑤打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java 工程对应 jar 包，Web
工程对应 war 包。
⑥安装：在 Maven 环境下特指将打包的结果——jar 包或 war 包安装到本地仓库中。
⑦部署：将打包的结果部署到远程仓库或将 war 包部署到服务器上运行。
(5)自动化构建

三.安装Maven核心程序

1.检查JAVA_HOME环境变量是否配置
2.解压Maven核心程序的压缩包
3.配置MAVEN_HOME并加入path路径下
4.命令行中输入mvn -v查看Maven版本

四.Maven 核心概念

Maven 能够实现自动化构建是和它的内部原理分不开的，这里我们从 Maven 的九个核心概念入手，
看看 Maven 是如何实现自动化构建的
①POM*
②约定的目录结构*
③坐标*
④依赖管理**
⑤仓库管理
⑥生命周期
⑦插件和目标
⑧继承
⑨聚合

1.POM

Project Object Model：项目对象模型。
将 Java 工程的相关信息封装为对象作为便于操作和管理的模型。Maven 工程的核心配置。
pom.xml对于Maven工程是核心配置文件与构建过程相关的一切都在这个文件中进行配置
重要程度相当于web.xml对于动态web工程

2.坐标

（1）几何中的坐标
[1]在一个平面中使用 x、y 两个向量可以唯一的确定平面中的一个点。
[2]在空间中使用 x、y、z 三个向量可以唯一的确定空间中的一个点。

（2） Maven 的坐标
使用如下三个向量在 Maven 的仓库中唯一的确定一个 Maven 工程。
[1]groupid：公司或组织的域名倒序+当前项目名称
[2]artifactId：当前项目的模块名称
[3]version：当前模块的版本

（3）Maven工程的坐标与仓库路径的对应关系
[1]将 gav 三个向量连起来
com.atguigu.maven+Hello+0.0.1-SNAPSHOT
[2]以连起来的字符串作为目录结构到仓库中查找
com/atguigu/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar

3.仓库

①仓库的分类
[1]本地仓库：为当前本机电脑上的所有 Maven 工程服务。
[2]远程仓库
(1)私服：架设在当前局域网环境下，为当前局域网范围内的所有 Maven 工程服务。
(2)中央仓库：架设在 Internet 上，为全世界所有 Maven 工程服务。
(3)中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的
响应用户请求。
②仓库中的文件
[1]Maven 的插件
[2]我们自己开发的项目的模块
[3]第三方框架或工具的 jar 包

4.依赖

①Maven解析依赖信息时会到本地仓库中查找被依赖的jar包
    对于我们自己开发的Maven工程，使用mvn install命令安装后就可以进入仓库
② jar 包的坐标还有一个 scope 设置，这是依赖的范围。
    依赖的范围有几个可选值，我们用得到的是：compile、test、provided 三个。
    （1）compile范围依赖
        对主程序有效，对测试程序有效，参与打包
    （2）test范围依赖
        对主程序无效，对测试程序有效，不参与打包
    （3）provided范围依赖
        对主程序有效，对测试程序有效，不参与打包，不参与部署
③依赖的传递性
    【1】好处：可以传递的依赖不必在每个模块工程中都重复说明，在工程中依赖一次即可
    【2】注意：非compile范围的依赖不能传递，在各个工程中，如果有需要就的重复声明依赖
④依赖的排除
    【1】需要设置依赖排除的场合:当有不稳的jar包，不希望加入当前工程
    【2】依赖排除的设置方式

        <exclusions>
               <exclusion>
                   <groupId></groupId>
                   <artifactId></artifactId>
               </exclusion>
        </exclusions>

⑤依赖的原则
    【1】作用：解决模块工程之间的jar包冲突问题
    【2】情景：由于依赖的传递性，导致某个包出现同名不同版本的依赖，此时选择路径最短者。
    验证路径相同时先声明者优先（dependency标签的声明顺序）

5，生命周期

    1.Maven 生命周期定义了各个构建环节的执行顺序，不能打乱顺序，必须按照正常的顺序来执行代码
    2.Maven的核心程序中定义了抽象的生命周期，生命周期中的各个阶段的具体任务是由插件来完成的
    3.Maven核心程序为了更好的实现自动化构建，按照统一的特点执行的各个阶段：无论现在要执行
    生命周期中的哪一个阶段，都是从这个生命周期最初的位置开始执行。
    Maven 有三套相互独立的生命周期，分别是：
    ①Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
    ②Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等等。
    ③Site Lifecycle 生成项目报告，站点，发布站点。
    它们是相互独立的，你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点。
    当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。
    每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。
    比如，运行 mvn clean，这个 clean 是 Clean 生命周期的一个阶段。有 Clean 生命周期，也有
    clean 阶段。
   （1）Clean 生命周期
        Clean 生命周期一共包含了三个阶段：
        ①pre-clean 执行一些需要在 clean 之前完成的工作
        ②clean 移除所有上一次构建生成的文件
        ③post-clean 执行一些需要在 clean 之后立刻完成的工作
   （2）Site 生命周期
        ①pre-site 执行一些需要在生成站点文档之前完成的工作
        ②site 生成项目的站点文档
        ③post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
        ④site-deploy 将生成的站点文档部署到特定的服务器上
        这里经常用到的是 site 阶段和 site-deploy 阶段，用以生成和发布 Maven 站点，这可是 Maven 相当强大
        的功能，Manager 比较喜欢，文档及统计数据自动生成，很好看。
   （3）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 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。

五.第一个Maven工程

1.默认目录存放规则

    根目录：工程名
    ---src目录：源码
    -------java目录：存放java源文件
    -------resources目录：存放框架或其他工具的配置文件
    ---test目录：存放测试程序
    -------java目录：存放java源文件
    -------resources目录：存放框架或其他工具的配置文件
    ---pom.xml：Maven工程的核心配置文件

2.为什么要遵守约定的目录结构

    约定的目录结构对于 Maven 实现自动化构建而言是必不可少的一环，就拿自动编译来说，Maven 必须
    能找到 Java 源文件，下一步才能编译，而编译之后也必须有一个准确的位置保持编译得到的字节码文件。
    我们在开发中如果需要让第三方工具或框架知道我们自己创建的资源在哪，那么基本上就是两种方式：
    ①通过配置的形式明确告诉它
    ②基于第三方工具或框架的约定
    Maven 对工程目录结构的要求就属于后面的一种。
    约定>配置>编码

3.常见的Maven命令

    ①注意：执行与构建过程相关的Maven命令，必须进入pom.xml所在的目录，与构建过程相关：
    编译，测试，打包
    ②常用命令
        mvn clean：清理
        mvn compile：编译主程序
        mvn test-compile：编译测试程序
        mvn test：执行测试
        mvn package：打包
        mvn install：安装
        mvn site：生成站点

4.关于联网问题

    ①Maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成，
    插件本身并不包含在Maven的核心程序中
    ②当我们执行的Maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找
    ③本地仓库的默认位置在当前用户的家目录
    ④Maven核心程序如果在本地仓库中找不到需要的插件，那么它会只自动连接外网，到中央仓库下载
    ⑤如果此时无法连接外网，则构建失败
    ⑥修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下查找插件
        （1）找到Maven解压目录\conf\settings.xml
        （2）在settings.xml文件中找到localRepository标签
        （3）将<localRepository>/path/to/local/repo</localRepository>从注释中取出
        （4）将标签内容修改为已经准备好的Maven仓库目录

5.Maven插件的设置

    （1）installations：指定Maven核心程序的位置，不建议使用插件自带的Maven程序，而
    应该使用自己解压的那个
    （2）user settings：指定conf/setting.xml的位置，进而获取本地仓库的位置
    （3）创建Maven的基本工程

六.继承

1.为什么需要继承机制？

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

2 创建父工程

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

3 在子工程中引用父工程

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

    此时如果子工程的 groupId 和 version 如果和父工程重复则可以删除。

4.在父工程中管理依赖

    将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来

    <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>

七.聚合

1 为什么要使用聚合？

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

2 如何配置聚合？

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

    <modules>
                 <!--指定子工程的相对路径-->
                <module>../Hello</module>
                <module>../HelloFriend</module>
                <module>../MakeFriends</module>
            </modules>