【Maven】Maven构建管理和插件配置

洛上言

于 2024-08-03 21:51:39 发布

阅读量416

点赞数 3

分类专栏： # Maven 文章标签： maven python linux

本文链接：https://blog.csdn.net/qq_39921135/article/details/140897667

版权

Maven 专栏收录该内容

16 篇文章 0 订阅

订阅专栏

在没有Maven命令之前，我们都是使用IDEA进行构建，当我们写好了对应的Java工程，我们只需要点击运行即可，整个构建过程基本上我们是没有任何参与的。

有了Maven后，Maven将整个构建过程中的这些动作对外进行暴露了，我们可以使用多种方式进行参与。

一、构建概念

项目构建是指将Java源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程，在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。

二、主动触发场景

重新编译：编译不充分，部分文件没有被编译!
打包：独立部署到外部服务器软件，打包部署
部署本地或者私服仓库：maven工程加入到本地或者私服仓库，供其他工程使用

注意和之前的部署概念区分，之前理解的部署是把web项目放到服务器软件的过程，而这个部署指的是将maven工程加入到本地或者私服仓库，供其他工程使用。

三、命令方式构建

语法：mvn 构建命令构建命令....

target是存储构建后的产物的，就像非Maven工程中有out文件夹是一样的。

命令	描述
mvn clean	清理编译或打包后的项目结构，删除target文件夹
mvn compile	编译项目，生成target文件
mvn test	执行测试源码 (测试)
mvn site	生成一个项目依赖信息的展示页面(不怎么用，因为我们依赖信息通过pom文件也是可以看见的)
mvn package	打包项目，生成war / jar 文件
mvn install	打包后上传到maven本地仓库(本地部署)，那么当前电脑上其他的Maven工程就可以引用它
mvn deploy	只打包，上传到maven私服仓库(私服部署)

对应关系如下图

注意事项：

命令执行需要我们进入到项目的根路径，与pom.xml平级，因为它需要读取你的pom.xml，最终才能进行构建。
部署必须是jar包形式，也就是说你只能是一个Java普通工程才能被别人引用；而web工程应该放到服务器软件，而不是放到仓库的。
多个命令可以一起使用，例如重新编译可以写成 mvn clean compile
package打包命令会自动识别你pom文件中的 packaging属性，如果没写packaging属性，那么默认就是jar包

执行 mvn package 后，target目录下就会出现该项目的jar包
mvn install：将target下的 project-1.0.0.jar 放到 D:\develop\mvn-repo 本地仓库中，存放的形式也是像我们之前一样，安装gav一层一层的最终放到这个对应的位置。
PS：我们执行的 mvn 都是命令，真正干活的其实都是插件

四、可视化方式构建

IDEA提供的可视化工具

五、构建命令周期

1）引入

如下图，清理指的是一个周期，使用的是 clean命令，对应的是一个清理插件，最终就完成了清理的动作。

因此真正干活的其实是插件，而我们是用命令去触发这个插件的。

编译也是一样，mvn compile 触发了 resources插件 和 compile插件，最终完成了整个编译的过程。

接下来我们再执行一下 mvn test，可以发现它触发了跟 compile 一样的插件

我们再来试一个打包

此时就发现了，后面执行的这些动作，都触发了前面的操作。

最后我们再来测试部署

由此可见，如果我们要编译部署的话，无需先compile，然后再package，最后install。

因此如果你想要部署，不需要先执行编译、测试、打包，而是直接install即可。

2）构建生命周期

Maven的生命周期就是为了对所有的构建过程进行抽象和统一。描述了一次项目构建，经历哪些阶段。

在Maven出现之前，项目构建的生命周期就已经存在，软件开发人员每天都在对项目进行清理，编译，测试及部署。虽然大家都在不停地做构建工作，但公司和公司间、项目和项目间，往往使用不同的方式做类似的工作。

Maven从大量项目和构建工具中学习和反思，然后总结了一套高度完美的，易扩展的项目构建生命周期。这个生命周期包含了项目的清理，初始化，编译，测试，打包，集成测试，验证，部署和站点生成等几乎所有构建步骤。

Maven构建生命周期可以理解成是一组固定构建命令的有序集合，触发周期后的命令，会自动触发周期前的命令！也是一种简化构建的思路！

Maven对项目构建的生命周期划分为3套（相互独立）：

清理周期：主要是对项目编译生成文件进行清理，比如编译之后的class文件、字节码文件等
默认周期(构建周期)：定义了真正构件时所需要执行的所有步骤，它是生命周期中最核心的部分，如：编译、测试、打包、安装、部署等。
报告周期：生成报告、发布站点等。

三套生命周期又包含哪些具体的阶段呢, 我们来看下面这幅图:

每套生命周期包含一些阶段（phase），阶段是有顺序的，后面的阶段依赖于前面的阶段。

我们看到这三套生命周期，里面有很多很多的阶段，这么多生命周期阶段，其实我们常用的并不多，主要关注以下几个：

clean：移除上一次构建生成的文件
compile：编译项目源代码
test：使用合适的单元测试框架运行测试(junit)
package：将编译后的文件打包，如：jar、war等
install：安装项目到本地仓库

在同一套生命周期中，我们在执行后面的生命周期时，前面的生命周期都会执行。

思考：当运行package生命周期时，clean、compile生命周期会不会运行？

clean不会运行，compile会运行。因为compile与package属于同一套生命周期，而clean与package不属于同一套生命周期。

默认周期package并不会进行clean，因此打包的最佳触发方式应该为： mvn clean package；编译的最佳触发方式： mvn clean compile；构造本地仓库的最佳触发方式：mvn clean install。

3）总结最佳使用方案

打包: mvn clean package
重新编译: mvn clean compile
本地部署: mvn clean install

4）周期，命令和插件之间的关系

周期→包含若干命令→包含若干插件!

使用周期命令构建，简化构建过程！

最终进行构建的是插件！由于一个个的触发插件太麻烦了，因此触发都是通过周期触发。

Maven的生命周期是抽象的，这意味着生命周期本身不做任何实际工作。在Maven的设计中，实际任务（如源代码编译）都交由插件来完成。

5）插件配置

每个Maven工程只要你创建了，都会包含Maven插件，而且这些版本都是会根据你Maven软件的不同，都有对应的版本。

但如果我想自己配插件怎么办？

场景：我们这个版本的Maven自动打包war包的这个插件是2.2，版本泰迪，无法兼容JDK17的打包方式

此时执行 package 就会报错

此时我们就需要配一个高版本的插件出来。

<!-- 导入插件，插件都是来辅助我们程序进行构建的，因此是放在build里面 -->
<build>
   <!-- jdk17 和 war包版本插件不匹配 -->
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>3.2.2</version>
        </plugin>
    </plugins>
</build>