YC-Maven学习

Maven学习：

maven存在的原因：（why）

1：一个项目就一个工程

​ 项目可以借助maven拆分成多个工程，可以实现共用jar包

2：项目中需要的jar包需要手动复制到WEB-INF/lib下面

​ 这样会出现大量重复的jar包，让程序变得比较臃肿，通过maven可以自己下载

3：jar包需要别人为我们准备好，或者去官网下载

​ 不用maven要下载jar包是五花八门的，如果使用maven就有一个统一的下载的地方，形成规范

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

​ 所有jar包的依赖关系，都需要程序员非常了解，增加学习成本，maven会自动将被依赖的jar包导 入进来

Maven是什么？(what)

​ maven是一款服务与java平台的自动化构建工具

构建过程中的各个环节：

​ 1.清理：将以前的旧的class文件删除

​ 2.编译：将java源文件编辑成class字节码文件

​ 3.测试：自动测试，自动调用junit程序

​ 4.报告：测试程序执行结果

​ 5.打包：动态Web工程打war包，java程序打的是jar包

​ 6.安装：将打包好的文件放到仓库中指定的位置

​ 7.部署：将动态的Web工程生成的war包复制到Servlet容器的指定目录下，使其可以运行

安装Maven核心程序

​ 1：检查java_home环境变量

​ 2：解压maven安装包并配置环境变量

​ 3：命令：mav -v 查看是否配置成功

Maven的核心概念：

1.预定的目录结构

2.POM

3.坐标

4.依赖

5.仓库

6.生命周期/插件、目标

7.继承

8.聚合

第一个maven工程

1：使用maven自动构建的时候，必须要遵守maven的项目目录结构

常用的maven命令

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

2：常用命令：

mvn clean：清理，清除

mvn compile：编译主程序

mvn test-compile：编译测试程序

mvn test：执行测试

mvn package：打包

mvn install：安装程序，安装后本地项目就进入了maven本地仓库中新建了一个坐标

关于联网的问题：

1：maven的核心程序中仅仅定义了生命周期，但是具体的工作必须由特定的插件来进行，但插件本身并没有在maven的核心程序中

2：当我们执行maven命令需要用到某些插件的时候，Maven核心程序会先到本地仓库中查找

3：本地仓库的默认位置：【系统中当前用户的家目录】.\m2\repository

4：maven核心程序如果在本地仓库中找不到需要的插件，那么他会自动连接外网到中央仓库去下载

5：修改本地仓库的位置：conf\strings.xml，找到：localRepository，取消注释，修改本地maven仓库

POM

1：含义：项目对象模型

2：pom.xml对于Maven工程是核心的配置文件，与构建过程中的一切都在这个文件中配置

坐标：

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

• groupid：公司或组织域名倒序+项目名
• artifactid：模块名称
• version：版本

仓库：

1：分为：本地仓库，远程仓库（局域网，中央仓库，中央仓库镜像）

2：仓库中保存的内容：Maven工程

依赖：

1：Maven解析依赖信息时，会到本地仓库中去查找本地依赖包，对于我们自己开发的maven工程，使用：mvn install，命令后就可以进入本地仓库

2：依赖范围：

• compile：表示主程序的依赖，main目录下，test目录下都可以使用，参与打包

• test：表示测试下的依赖，只有在test目录下可以使用，不参与打包

• provided：main目录下可以使用，test目录下可以使用，不参与打包，不参与部署

  如果一个工程需要依赖自己的另一个工程的类，就需要在pom中写上另一个工程的坐标，因为我们的maven仓库中不仅存了远程仓库下载下来的依赖，还有我们本地项目的依赖

在idea中使用Maven

1. 指定maven程序路径
2. user settings：指定conf/settings.xml的位置，进而获取本地仓库位置，可以在文件中进行修改
3. 创建maven的时候建议勾选Create from archerype

依赖高级（内层的modeo都依赖外层的modeo）

1. 依赖传递性，好处可以传递的依赖不必在每个工程都重复声明，只需要在最外层一栏一次就可以，注意：只有compile依赖可以进行传递

2. 依赖排除，有些不稳定的依赖，自己的项目不需要传递，可以设置依赖排除，如内层的modeo想要排除外层某一个依赖，在引用外层总的依赖的时候加入：exclusion标签

3. 依赖的原则：作用解决模块中jar包冲突问题

   原则1，路径最短者优先：C依赖B，B依赖A，此时A和B都同时声明了一个依赖的不同版本，那么C应该会依赖于路径最短者B下的这个依赖的版本

   原则2，先声明者优先：C依赖B，还依赖了A，此时A和B都同时声明了一个依赖的不同版本，那么C会先按照B,A的dependency标签的声明顺序取前面的依赖

   原则3，场景：一个项目中有多个Spring的jar包，的依赖版本都是4.0.0，如果需要统一升级比较麻烦容易出错，所以需要使用配置

   //使用properties标签自定义标签统一生成版本号
   <properties>
       <atguigu.sping.version>4.0.0RELEASE</atguigu.sping.version>
   </properties>
   //在依赖的version处用${自定义标签名}引用声明的版本号
   <version>${atguigu.spring.version}</version>
   

继承：

• 现状：有时候项目中的各个模块用的依赖可能不一致，会导致各个模块中使用的方法有区别，相同的代码在不同模块中可能会有异常，所以maven出现了继承这个概念，统一管理各个模块中的依赖版本，保持一致

• 解决思路，将依赖的版本统一提取到父工程中，在子工程中声明依赖时不指定版本，以父工程中统一的版本为准

• 操作步骤：

  1. 创建工程父工程，注意：打包方式pom

     <!--父工程坐标&打包的方式-->
     <groupId>com.tal.wangxiao</groupId>
     <artifactId>conan</artifactId>
     <version>1.0.0</version>
     <packaging>pom</packaging>
     

  2. 在子工程中声明对父工程的引用表示父工程标签

     <!--子工程中声明父工程-->
     <parent>
             <artifactId>conan</artifactId>
             <groupId>com.tal.wangxiao</groupId>
             <version>1.0.0</version>
             <!--此时可以加上这个标签，表示：以当前文件为基准,可加可不加-->
             <relativePath>../conan.pom.xml</relativePath>
     </parent>
     

  3. 将子工程的坐标中与父工程的坐标中重复的内容删除：当子工程的坐标上面出现黄线，提示重复后可以将相同的依赖删除

  4. 在父工程中统一管理junit的依赖

     <!--父工程中声明junit版本-->       
     <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>4.13</version>
     </dependency>
     

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

     <!--此时子工程中就不必再声明版本号了-->
     <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
     </dependency>
     

• 注意：配置继承后，install的时候，必须要先install父工程

聚合

• 作用：一键安装各个模块工程

• 配置方式：在一个“总的聚合工程”中配置各个参与聚合的模块，执行install就可以实现一键安装

  <!--配置聚合-->
  <modules>
      <!--指定各个子工程的相对路径-->
          <module>conan-common</module>
          <module>conan-admin</module>
  </modules>