01_自动化构建工具之Maven

2022-10-01 17:42:47

  • 目前技术中存在问题（为什么使用Maven）：
  1. 一个项目就是一个工程：
    1. 缺陷：如果项目太过庞大，就不适合使用package来划分层次，最好是一个模块就是一个工程，利于分工协作。
    2. 解决：Maven可以将一个项目拆分成多个工程。
  2. 项目中所需要的jar包必须手动“复制”“粘贴”到WEB-INF/lib中：
    1. 缺陷：同样的jar包出现在不同的工程中，造成磁盘存储空间的浪费，同时造成工程臃肿。
    2. 决：借助Maven可以将jar包保存在仓库中，然后在项目中添加一个“引用”文件接口即可。
  3. jar包需要提前下载好，或者别人事先准备好：
    1. 缺陷：不同的官网提供jar包下载的方式不同，通过非官网下载则可能导致jar包不规范（收费、版本）。
    2. 解决：所有的jar包都在Mven的*仓库中存储，可以使用规范的方式下载所需要的jar包。
  4. jar包需要手动添加依赖包
    1. 缺陷：jar包之间具有依赖性，如commons-filedupload.jar包依赖于commons-io.jar包，在使用这些jar包时，必须要                            掌握其中的依赖关系。
    2. 解决：使用maven，会自动将依赖包导入到项目中。
  • Maven是什么：
    • ①.Maven是一款只针对Java平台的自动化构建工具
    1. 发展历程：Make→Ant→Maven→Gradle
  • ②. 构建
      1. 概念：以“Java源文件”“框架配置文件”“jsp”“html”“图片”等资源文件为“原材料”，去“生产”一个可以            运行的项目的过程。
      2. 编译：Java源文件→编译→Class字节码文件→交给JVM去执行       。
      3. 部署：一个动态web项目最终运行的并不是项目本身，而是这个项目“编译的结果”。
      4. 构建：构建并不等于创建，构建就是以我们编写的Java文件、框架配置文件、国际化等资源文件、图片和jsp页面等             静态资源作为“原材料”，生产出一个可运行的项目的过程。
    • ③.构建过程中的各个环节：
      1. 清理：将以前编译得到的旧的class字节码文件删除
      2. 编译：将Java文件编译为class字节码文件
      3. 测试：自动测试，自动调用JUnit程序
      4. 报告：将测试的结果打印出来
      5. 打包：动态Web工程打包为war，Java工程打包为jar
      6. 安装：Maven特定概念--将打包得到的文件复制到“仓库”指定位置
      7. 部署：将动态web工程打包而成的war包复制到servlet容器的指定目录下。
    • Maven环境配置：
      1. Java环境变量配置
      2. 解压缩Maven压缩文件，并创建一个新的目录进行存放
      3. 配置Maven环境：
        1. 配置MAVEN_HOMT或M2_HOME:01_自动化构建工具之Maven
        2. 配置Maven的path环境：01_自动化构建工具之Maven
        3. 验证Maven安装是否成功：mvn -v,显示当前版本信息后则安装成功
      • Maven的核心概念：
        1. 约定的目录结构
        2. POM
        3. 坐标
        4. 依赖
        5. 仓库
        6. 生命周期/插件/目标
        7. 继承
        8. 聚合
        • .第一个Maven工程：
          • 创建约定的目录结构：
        1. 根目录：工程名
        2. src目录：源码
        3. POM.xml文件：Maven工程的核心配置文件
        4. main目录：存放主程序
        5. test目录：存放测试程序
        6. java目录：存放Java源文件
        7. resources目录：存放框架或者其他工具的配置文件
        • 为什么要遵守约定的目录结构？
        1. 为了自动化构建
      • 常用命令：
          • 注意：执行与构建过程相关的maven命令，必须进入pom.xml所在目录。与构建过程相关：编译、测试、打包......
          • 常用命令：
        1. mvn clean:清理
        2. mvn compile:编译主程序
        3. mvn test-compile:编译测试程序
        4. mvn test:执行测试
        5. mvn package：打包
        6. mvn install:安装
        7. mvn site：生成站点
      • 关于Maven联网问题：
          • Maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成。而插件本身并不包含在Maven的核心程序
          • 当我们使用的Maven命令需要用到一些别的插件时，Maven核心程序会先到电脑本地的仓库中寻找
          • 本地仓库的默认位置为（c:\users\Administor\.m2\repository）
          • Maven如果在本地仓库无法找到需要的插件，会自动连接外网在*仓库中下载
          • 如果无法联网，则构建会失败
          • 修改默认本地仓库位置，可以让Maven核心程序到事先准备好的目录下寻找插件
        1. Maven解压目录\conf\setting.xml
        2. 在setting.xml中找到ocalRepository标签
        3. 将<localRepository>/path/to/local/repo</localRepository>
        4. 将标签中间的路径修改为早已准备好的maven仓库目录
        5. <localRepository>D:\Work\Environment\Maven\local</localRepository>
      • POM文件
          • 全拼：Project Object Model 项目对象模型
            • Dom ：Document Object Model 文档对象模型
          • pom.xml文件是Maven的核心配置文件，与构建过程相关的一切设置都这pom.xml中进行
        • 坐标：
          • 数学中的坐标：
        1. 在平面中，使用x、y两个向量，可以在平面中确定唯一的一个点
        2. 在空间中，使用x、y、z三个向量可以在空间中确定唯一的一个点
      • 在Maven中使用以下三个向量来确定唯一的Maven工程
        1. groupId:公司/组织域名倒序+项目名
        • <groupId>pw.fengya.maven</groupId>
      • artifactId:模块名
        • <artifactId>Hello</artifactId>
      • version:版本
        • <version>1.0.0</version>
      • 坐标与仓库中的路径的对应关系
      • 仓库
          1. 仓库分类：
          • 本地仓库：在当前电脑上部署的Maven仓库目录，只为当前电脑的Maven工程服务
          • 远程仓库：
          1. 私服(Nexus)：架设在局域网环境下，为当前局域网环境下的Maven工程服务
          2. *仓库：架设在Internet上，为全世界的Maven工程服务
          3. *仓库镜像：为了分担*仓库的流量压力，提升用户访问速度
        • 仓库中保存内容(Maven工程)：
          • Maven自身所需要的插件
          • 第三方框架或工具所需jar包
          • 自己开发的Maven工程
        • 依赖
          • Maven解析依赖信息时会到本地仓库中寻找被依赖的jar包
            • 对于我们自己开发的Maven工程，使用mvn install命令后就可以进入仓库
          • 依赖的取值：
            • compile范围依赖
              • 对主程序是否有效：有效
              • 对测试程序是否有效有效
              • 是否参与打包：参与
            • test
              • 对主程序是否有效：无效
              • 对测试程序是否有效：有效
              • 是否参与打包：不参与
              • eg:junit.jar
            • provided：
            • 对主程序是否有效：有效
            • 对测试程序是否有效：有效
            • 是否参与打包：不参与
            • 是否参与部署：不参与
            • eg:servlet-api.jar
          • Maven生命周期：
            • 各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行
            • Maven的核心程序中定义了抽象的生命周期，生命周期各个阶段的具体任务由插件来完成
            • Maven核心程序为了更好的实行自动化构建，按照这些特点来执行生命周期中的各个阶段：不论现在要执行生命周期中的哪一个阶段，都是从这个生命周期的最初开始执行。
          • 在Eclipse中使用Maven插件
            • Maven插件：Eclipse内置
            • Maven插件设置：
              • 在installation中添加自己本地的Maven仓库目录
              • 在user setting中设置conf/setting.xml的位置
            • 创建Maven工程：
              • 创建Java工程，选择打包方式为jar
              • 创建web工程，选择打包方式为war，并选中项目，选择properties，选择Project Facets，去掉Dynmic  web Module,点击Apply，重新勾选，并勾选在src/main/webapp目录下创建web.xml
            • jsp页面抛空指针异常，则可能是依赖范围问题，将socpe属性值改为provided
          • 依赖[高级]：
            • 依赖的传递性：
              • 好处：可以传递的依赖不必再每个模块都进行声明，在“最下面”的工程中依赖一次即可
              • 注意：只有compile范围的依赖可以进行传递
            • 依赖的排除：
              • 在某个项目中确实需要依赖某jar包，而其传递的依赖中可能有jar包并不稳定，所以需要排除
              • 排除设置：
              • <exclusions>
                
        <exclusion>
                
                  <groupId></groupId>
                
                   <artifactId></artifactId>
                
        </exclusion>
                
</exclusions>
          • 依赖的原则：
            • 作用：解决模块jar包之间的冲突性问题
            • 情景设定1：声明路径不同时，路径较短者优先
            • 情景设定2：声明路径相同时，先声明者优先
              • 此处路径相同指的是dependency标签的先后顺序
          • 依赖版本管理：
            • 情景设定：加入当前项目使用的spring版本为4.0.0，假如后期需要修改版本号为4.0.2时，不可能依靠手动修改
              • 解决方案：在properties标签中使用自定自定义标签统一声明版本号
              • <properties>
                
        <自定义标签名>版本号</自定义标签名>
                
</properties>
            • 在需要同一版本的位置，使用${自定义标签名}声明引用的版本号
            • 使用properties标签和自定义标签的方式并不是只适合于版本号的设定，也可以用于其他地方，类似于Java中的常量
          • 继承：
            • 现状：
              • JavaProject01依赖的Junit版本：4.0
              • JavaProject02依赖的Junit版本：4.0
              • JavaProject03依赖的Junit版本：4.9
              • 缺陷：由于test范围的依赖不能传递，所以必然会导致各模块版本不一致
            • 需求：统一管理各个模块对于Junit的版本管理
            • 解决思路：将Junit统一提取到“父”工程中，在子工程中声明Junit依赖时不指定版本，以父工程统一设定为准，也利于修改。
            • 操作步骤：
              • 创建一个Maven工程为父工程，注意：打包方式为pom
                            01_自动化构建工具之Maven
          • 在子工程中声明对父工程的引用
          • 将子工程中与父工程冲突的部分删掉
          • 在父工程中统一对Junit的依赖
          • 在子工程中删除对于Junit依赖的版本号      
             01_自动化构建工具之Maven
          • 配置完成后，需要先安装父工程再安装子工程
          • 聚合：
            • 作用：一键自动安装各个模块工程
            • 配置方式：在一个“总的聚合工程”中配置参与聚合的各个模块
              • 01_自动化构建工具之Maven01_自动化构建工具之Maven
            • 使用方式：在聚合工程中run as 选择Maven install
           
          上一篇：ASP.NET MVC5（四）：数据注解和验证


          下一篇：Linux相关问题-CentOS6.5 x64版本号下Tomcat无法自启动的解决的方法