Maven

张萌杰

已于 2022-05-23 16:45:47 修改

阅读量131

点赞数

文章标签： maven

于 2022-04-09 20:49:02 首次发布

本文链接：https://blog.csdn.net/weixin_43687024/article/details/124061951

版权

java初学专栏收录该内容

15 篇文章 1 订阅

订阅专栏

回顾：
1，软件分层（三层）：
（1）视图层/表示层/表述层/表现层
视图层：
h5/css/js/jsp （其中：jsp的本质是Servlet，后端）
控制层：
servlet/action/handler（负责接收请求参数，处理请求，返回响应，跳转页面）
（2）业务逻辑层
Spring IOC AOP
（3）持久化层
数据库相关
jdbc/DBUtils/SpringTemplate/Hibernate/MyBatis

Maven

一，Maven解决的问题：

（1）当项目非常庞大，需要将每个模块对应分成一个工程，方便分工合作。而借助maven就可以将一个项目拆分成多个工程。
（2）jar包重复出现在不同的项目工程中，浪费了储存空间。而借助maven可以将jar包仅仅保存在“仓库”中，就不需要把jar复制过去。
（3）不用再去官网或他人那里下载jar包。有些技术就是通过maven提供下载。maven的下载渠道是正规的，因为所有知名框架或第三方工具的jar包都按照maven统一的规范放在了maven的中央仓库中。
（4）jar包的其他jar需要再手动导入，会很麻烦。而maven可以自动导入。减少学习成本，不需要必须搞清楚jar包之间的依赖关系。

二，Maven是什么

1，是一款服务于Java平台的自动化构建工具。
Make->Ant->Maven->Gradle
2，构建：
（1）概念：以“Java源文件”，“框架配置文件”，“JSP”，“HTML”，“图片”等资源为“原材料”，去“生产”一个可以运行的项目的过程。

编译
部署
搭建

（2）编译：

Java源文件【User.java】
编译
Class字节码文件【User.class】
交给JVM去执行

（3）部署：一个BS项目最终运行的并不是动态Web工程本身，而是这个动态Web工程“编译的结果”

动态Web工程
编译，部署
编译结果

注意1：根据不同环境，不同版本，编译器等，最终编译出的文件里的路径也可能不同。（注意：可能会导致一些页面跳转等出现找不到页面情况）（一般src下的文件会在WEB-INF的classes下。而WebContent里的文件则会直接出现在根目录的下一级，即和WEB-INF在同一目录下，平级。）
注意2：所以开发过程中，所有的路径或配置文件中配置的类路径等都是以编译结果的目录结构为标准的。

部署：将Java程序的Web工程编译的结果”拿“到服务其上的指定目录下，并启动服务器。其中”拿“的过程叫部署。

3，构建过程中的各个环节
（1）清理：将以前编译得到的旧的class字节码文件删除，为下一次编译做准备
（2）编译：将Java源程序编译成class字节码文件
（3）测试：自动测试，自动调用junit程序
（4）报告：测试程序执行结果
（5）打包：动态Web工程打war包，Java工程打jar包
（6）安装：（Maven特定的概念）将打包得到的文件复制到”仓库“中的指定位置
（7）部署：将动态Web工程生成的war包复制到Servle容器的指定目录下，使其可以运行
4，自动化构建
又称：脚本

三，安装Maven核心程序

1，检查JAVA_HOME环境变量
2，下载解压到没有中文和空格的路径下
3，配置Maven的环境变量：（1）MAVEN_HOME 和 M2_HOME（M2不是刚需，但最好配上，能避免一些问题）；（2）path
4，在命令提示符中输入：mvn -v 检测是否安装成功

四，Maven的核心概念

1，约定的目录结构
2，POM
（1）含义：Project Object Model 项目对象模型
（DOM：Document Object Model 文档对象模型）
（2）pom.xml对于Maven工程时核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置。（重要程度相当于web.xml对于动态Web工程）
3，坐标
（1）数学中的坐标：

在平面上使用x，y两个确定平面内任何一点
在空间中使用x，y，z三个确定空间中的一点
（2）maven中的坐标
使用下面三个向量在仓库中唯一定位一个maven工程
groupid：公司或组织域名倒序+项目名

    <groupId>com.at.mvc</groupId>

artifactid：模块名

    <artifactId>springMVC-1</artifactId>

version：版本

    <version>1.0-SNAPSHOT</version>

（3）maven工程的坐标与仓库中路径的对应关系
举例：

    <groupId>com.at.mvc</groupId>
    <artifactId>springMVC-1</artifactId>
    <version>1.0-SNAPSHOT</version>

com.at.mvc/springMVC-1/1.0-SNAPSHOT/springMVC-1-1.0-SNAPSHOT.jar

注：

SNAPSHOT：快照版本，不稳定
RELEASE：开发完成的版本，较稳定

4，依赖
（1）Maven解析依赖信息时会到本地仓库中查找被依赖的jar包；对于我们自己开发的maven工程，使用install命令安装后就可以进入仓库。
（2）依赖的范围

main主程序依赖-compile范围的依赖。
test测试程序依赖-test范围的依赖和compile范围的依赖。
（测试程序可以将主程序导入，而主程序发现不了测试程序）

compile范围依赖：（开发，部署，运行）（1）对主程序是否有效：有效（2）对测试程序是否有效：有效（3）是否参与打包：参与（4）是否参与部署：参与（5）例子：spring-core。
test范围依赖：（1）对主程序是否有效：无效（2）对测试程序是否有效：有效（3）是否参与打包：不参与（4）例子：junit（5）是否参与部署：不参与。
provided范围依赖：（开发）（1）对主程序是否有效：有效（2）对测试程序是否有效：有效（3）是否参与打包：不参与（4）是否参与部署：不参与（5）例子：servlet-api.jar。

注：依赖范围也很重要，尽量避免和其他冲突；如tomcat自带一些jar，则不应该再将其范围设置成compile

（4）依赖的传递性：工程之间的依赖会传递，不必再每个模块工程中都声明，在“最下面”的工程中依赖一次即可。（非compile范围的依赖不能传递，如果有需要就得重复声明）
（5）依赖排除操作

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

只对当前工程有影响，但在“最下面”的工程中设置的话，其他工程也会排除。

（6）依赖的原则

作用：解决模块工程之间的jar包冲突问题
情景设定1：验证路径最短者优先原则
情景设定2：路径相同时，先声明者优先（先声明指的是dependency标签的声明顺序）
（7）统一管理依赖的版本
如果要对许多jar统一升级，手动逐一修改不可靠
建议：（1）使用properties标签内使用自定义标签统一声明版本号；（2）在需要统一版本的位置，使用${自定义标签名}引用声明的版本号
自定义：

    <properties>
        <lizi>1.0-SNAPSHOT</lizi>
    </properties>

引用它：

        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>${lizi}</version>
        </dependency>

且此方法不只是可以应用于此，凡是需要在统一声明后再引用的场合都可以使用

5，仓库
（1）仓库分类：

本地仓库：当前电脑上部署的仓库目录
远程仓库：（1）私服（局域网中）；（2）中央仓库（在Internet上，为世界所有Maven工程服务）；（3）中央仓库镜像（为了分担中央仓库的流量，提升用户体验）；
（2）仓库中保存的内容：Maven工程
Maven自身所需要的插件
第三方框架或工具的jar包（第一方：JDK；第二方：自己）
我们自己开发的Maven工程

6，生命周期/插件/目标
（1）各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。
（2）Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。
（3）Maven核心程序为了更好的实现自动化构建，按照这一的特点执行生命周期中的各个阶段：不论现在要执行生命周期中的哪一个阶段，都是从这个生命周期最初的位置开始执行。
（4）插件和目标

生命周期的各个阶段仅仅定义了要执行的任务是什么
各个阶段和插件的目标是对应的
相似的目标由特定的插件来完成
可以将目标看作“调用插件功能的命令”
7，继承
（1）由于test范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致。
（2）举例：统一管理各个模块工程中对junit依赖的版本；解决思路：将jumit依赖统一提取到“父”工程中，在子工程中声明依赖时不指定版本，以父工程中统一设定的为准。同时也便于修改。
（3）步骤
创建一个Maven工程作为父工程。（注意：打包方式为pom）
在子工程中声明对父工程的引用
将子工程的坐标中与父工程坐标中重复的内容删除
在父工程中统一junit的依赖
在子工程中删除junit依赖的版本号部分
子工程中：

    <!--子工程中声明父工程-->
    <parent>
        <groupId>com.at.mvc</groupId>
        <artifactId>springMVC-1</artifactId>
        <version>1.0-SNAPSHOT</version>

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

父工程中：

    <!--配置依赖的管理-->
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>4.10</version>
                <scope>test</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

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

8，聚合
（1）作用：一键安装各个模块工程
（2）配置方式：在一个“总的聚合工程”中配置各个参与聚合的模块

    <!--配置聚合-->
    <modules>
        <!--指定各个子工程的相对路径-->
        <module>../1</module>
        <module>../2</module>
        <module>../3</module>
    </modules>

（3）使用方式：在聚合工程的pom.xml上点击运行

五，创建一个Maven工程（约定的目录结构）

1，创建约定的目录结构
（1）根目录：工程名
（2）src目录：源码
（3）pom.xml文件：Maven工程的核心配置文件
（4）main目录：存放主程序
（5）test目录：存放测试程序
（6）java目录：存放java源文件
（7）resources目录：存放框架或其他工具的配置文件
2，遵守约定的目录结构

Maven负责我们这个项目的自动化构建，以编译为例，Maven要想自动进行编译，那么它必须要知道Java源文件保存在哪里。
如果我们自己自定义的东西想要让框架或工具知道，有两种方法：（1）以配置的方式明确告诉框架；（2）遵守框架内部已存在的约定。
约定>配置>编码

3，常用Maven命令
（1）注意：执行与构建过程相关的Maven命令，必须进入pom.xml所在的目录。

与构建过程相关：编译、测试、打包、···
（2）常用命令：
mvn clean：清理
mvn compile：编译
mvn test-compile：编译测试程序
mvn test：执行测试
mvn package：打包
mvn install：安装
mvn site：生成站点

六，关于联网问题

1，Maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成。而插件本身并不包含在Maven的核心程序中。
2，当我们执行的Maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找。
3，本地仓库的默认位置：【系统中当前用户的家目录】.m2\repository
4，Maven核心程序如果在本地“仓库”中找不到需要的插件，那么它会自动连接到网络，到“中央仓库”下载。
5，如果无法连接到网络，则构建失败
6，修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下查找插件