Maven学习简记

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/qq_38016931/article/details/81437083

此简记是在看教学视频时随便写在sublime上的，后面越写越多，才后悔没有将其写在csdn上，现在重新整理，整理这篇没有图片，没有多少代码比较随意的笔记，只希望以后能提醒自己已经忘却的，巩固些不熟练的知识，并没有什么可看性，慎看！除非是真的闲！

目录

软件分层概念：一个项目总体分三层

• 视图层： 视图层 h5/css/js/jsp

• 控制层 servlet

• 业务逻辑层: spring IOC AOP

• 持久化层：jdbc/DBUtils/spring JDBCTemplate/hibernate/MyBatis

• （其他）DB数据库：mysql/oracle

开发中存在的问题

• 一个项目就是一个工程
  
  • 如果项目很庞大，就不适合用package来进行模块划分，最好每一个模块对应一个工程，利于分工协作。
  • 借助于maven可以将一个项目拆分为多个工程！
• 项目中的jar包必须手动复制粘贴到项目的web/lib下
  
  • 带来的问题是同样的jar包文件出现在不同的项目工程中，浪费空间，让项目变得臃肿。
  • 使用maven可以将jar包仅仅保存在仓库中。，有需要使用的工程使用这个接口，并不需要导入真的jar包！

• jar包需要别人准备好，或到官网下载！
  

  • 不同的技术官网下载的jar包形式五花八门。
    
    • 有些技术的官网就是通过maven或svn等专门的工具提供下载的。
    • 如果是以非正规的方式下载的jar包，其中的内容可能是不规范的！
    • 借助于maven可以以一种规范的方式下载jar包，因为所有知名的框架或第三方工具jar包以及按照统一的规范放在了maven的中央仓库中！
      

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

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

• maven会自动将依赖的jar包导入进来！

什么是maven

• maven是一款服务于java平台的自动化构建工具。

  几款类似工具Make->Ant->Maven->Gradle

• 构建

  概念：以“java源文件”、“框架配置文件”、“jsp”、“html”、“图片”等资源为原材料，去生产一个可运行的项目的过程！

一个maven的项目文件基本结构:

src
- main java代码文件夹
- test 测试文件
- pom.xml maven的配置文件

junit的静态导入，那么junit jar包中的静态资源就可以直接用了！

常用的maven命令

• 注意：与构建过程相关的命令执行与构建过程相关的maven命令，必须要进入pom.xml躲在的目录。
• 常用命令
  ▲mvn clean 清理
  ▲mvn compile 编译主程序
  ▲mvn test-compile 编译测试程序
  ▲mvn test 执行测试
  ▲mvn package 打包

关于联网问题

• maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件完成，而插件并不包含在maven的核心程序中。
• 当我们执行maven命令需要用到某些插件时，maven核心程序会首先到本地仓库中查找。
• 本地仓库的位置[系统当前用户的系统目录].m2\repository
• maven核心程序如果在本地仓库中找不到需要的插件，那么他会自动连接到网络，到中央仓库下载！
• 如果不能联网，就构建失败

pom：project object model项目对象模型

• pom.xml对于maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件夹中进行配置，重要程度相当于webproject中的web.xml！

坐标:maven中的坐标：使用三个向量在仓库中唯一定位一个maven工程

• groupId:公司组织域名+项目名
• artifactId：模块名
• version:版本

仓库

• 仓库的分类：
  ▲本地仓库：当前电脑上部署的仓库目录，为当前电脑所有的maven工程服务
  ▲中央仓库：架设在Internet，为全世界maven工程服务。
  ▲中央仓库镜像：为了分担中央仓库的流量，提升用户访问速度！
• 仓库中保存的内容，Maven工程
  ▲maven自身需要的插件
  ▲第三方框架或工具的jar包
  ▲我们自己开发的maven工程

关于依赖

• maven解析依赖信息时会在本地库中查找被依赖的jar包
• 对于我们自己开发的Maven工程，使用命令install进行安装就可以进入本地仓库
• 依赖的范围：
  ▲compile，认识这个依赖的范围，从三个方面认识：
  对主程序是否有效，有效
  对测试程序是否有效，有效
  对打包是否有效，有效
  参与部署
  ▲test
  对主程序是否有效，无效
  对测试程序是否有效，有效
  对打包是否有效，无效
  不参与部署
  ▲provided
  对主程序是否有效，有效
  对测试程序是否有效，有效
  对打包是否有效，无效
  是否参与部署，不参与
  典型的例子就是servlet api由服务器自动提供

生命周期（比如 compile test package install是按先后顺序的，执行某一个，都是从第一步开始，执行例子中前面所有的步骤）

• 表示的是各个环节的先后顺序：不能打乱顺序，必须按照既定的正确顺序来执行
• maven的核心程序中定义了抽象的生命周期，生命周期中各个环节的任务由程序决定！
• Maven和兴程序为了更好的实现自动化构建，按照这一的特点执行生命周期的各个阶段；不论现在要执行生命周期的那个阶段，都是从这个生命周期最初的位置开始执行的。
• 插件和目标，懒得写，了解下就好了！

依赖的传递性

• 当一个依赖被使用，这个依赖所添加了的依赖就是被添加了这个依赖的工程添加了！
• 非compile范围的依赖不可传递

依赖的排除

• 和上面的是相反的操作，添加的依赖对别的包有依赖，使用依赖的工程去除这个简介的依赖！
• 依赖排除的设置,在依赖中添加一下配置：

<dependency>
    <exclusion>
        <groupId>...</groupId>
        <artifactId>...</artifactId>
    </exclusion>
</dependency>

依赖的原则

• 作用：解决模块工程之间的jar冲突问题
• 情景设定1（符合验证路径最短则优先）： 工程依赖两个包，而这两个包分别依赖同一个依赖的不同版本号，那么该工程就会遵循就近原则，那个依赖近就依赖哪个！
• 情景设定2（先声明者优先）：如果上述的路径长度相同，哪一个依赖优先声明，就依赖哪个！

统一管理依赖的版本

• 比如一个依赖的所有jar包都为4.0.0，那如果需要升级为4.0.1怎么操作？手动修改不可靠！
• 建议配置方式：
  ▲在properties标签内使用自定义标签统一声明版本号！

<properties>
    <cn.jxufe.version>4.0.0.RELEASE</cn.jxufe.version>
</properties>

需要统一版本的位置，使用${自定义标签名}引用声明的版本号！

<version>
     ${cn.jxufe.version}
</version>

• properties并不是只能管理版本号，其他的也能用！
  ▲像文件编码格式

继承

• 需求：统一管理各个模块工程中对某个依赖的版本，比如多个模块添加的多个相同的依赖版本不一样，而又由于test范围不可传递，相同的依赖会分散在各个模块中，造成版本不一致！
• 解决思路：将这个依赖统一提取到“父”工程中，在子工程中声明这个依赖不指定版本，以父工程中统一设定为准，同时也便于修改。
• 操作步骤
  
  1. 创建一个Maven工程为父工程，注意：打包方式为pom

<packaging>pom</packaging>

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

<parent>
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <version>...</version>

    <!--以当前工程的pom.xml文件为基准的父工程的pom.xml文件的相对路径-->
    <relativePath>...</relativePath>
</parent>

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

应该会有提示的，到时候实战操作！

    4. 在父工程中统一管理某个jar包的依赖

<dependencyMangement>
    <dependencies>
        <dependency>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
            <version>...</version>
            <scope>...</scope>
        </dependency>
    </dependencies>
</dependencyMangement>

5. 在子工程中删某个jar包的依赖版本号部分
    即父工程统一管理了依赖版本，子工程中的依赖版本就不需要了
    注意：配置继承后，执行安装命令时要先安装父工程！

聚合

• 作用：一键安装各个模块的工程
• 配置方式：在一个“总的聚合工程”中配置各个参与聚合的模块。
  在pom中添加：

<modules>
    <module>模块1</module>
    <module>模块2</module>
    <module>模块3</module>
    <module>...</module>
</modules>

• 操作方式：mvn install

写在最后

以上所述已由我在Intellij IDEA上实际操作过，虽然如此，随着时间的推移还是会将很多东西忘的一干二净，希望以后用到（可能会一直用，因为当初导包真的搞得我半死），自己不需要再重新看一遍长长的视频，而只是看看这个就能记起大半，就够了！