maven笔记
1. maven介绍
官网:Maven
下载地址:Download
Maven 是 Apache 软件基金会组织维护的一款专门为 Java 项目提供构建和依赖管理支持的工具。
2. 安装和配置
windows平台选择 apache-maven-x.x.x-bin.zip下载,下载后解压到不含中文、无空格的路径。
2.1. settings配置修改
conf/settings.xml文件需要修改。主要修改点如下:
<!-- 配置maven本地仓库的存放位置。默认在C盘。要从注释中拿出来。不需要建这个目录。要求目录中文无空格。 -->
<localRepository>D:/0.devEnv/mavenRepository</localRepository>
...
<!-- 配置阿里云提供的镜像仓库。也可替换为华为云、腾讯云等。 -->
<mirrors>
<mirror>
<id>nexus-aliyun</id>
<mirrorOf>central</mirrorOf>
<name>Nexus aliyun</name>
<url>https://maven.aliyun.com/repository/central</url>
</mirror>
</mirrors>
...
<!-- 配置Maven工程的基础JDK版本 -->
<profiles>
<profile>
<id>jdk-1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
<profiles>
阿里云的仓库地址已发生变更。很多教材还是使用的老地址。新旧地址的对应关系参考官网:https://maven.aliyun.com/repository/central
2.2. 环境变量配置
- 添加环境变量
MAVEN_HOME
,值为maven程序的地址(bin\的上一级)。如D:\0.devTools\1.maven\maven
- 把
%MAVEN_HOME%\bin
添加到path
中。
2.3. 验证
新开一个cmd窗口,执行mvn -v
,如果能看到版本号,说明配置成功。
3. 基本概念
3.1. maven中的坐标
使用三个**『向量』在『Maven的仓库』中唯一的定位到一个『jar』**包。
- groupId:公司或组织的 id
- artifactId:一个项目或者是项目中的一个模块的 id。一般作为 Maven 工程的工程名。
- version:版本号,根据自己的需要设定
- 例如:SNAPSHOT 表示快照版本,正在迭代过程中,不稳定的版本
- 例如:RELEASE 表示正式版本
坐标:
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
上面坐标对应的 jar 包在 Maven 本地仓库中的位置:
Maven本地仓库根目录\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar
3.2. POM
3.2.1. 含义
POM:Project Object Model,项目对象模型。和 POM 类似的是:DOM(Document Object Model),文档对象模型。它们都是模型化思想的具体体现。
3.2.2. 模型化思想模型化思想
POM 表示将工程抽象为一个模型,再用程序中的对象来描述这个模型。这样我们就可以用程序来管理项目了。我们在开发过程中,最基本的做法就是将现实生活中的事物抽象为模型,然后封装模型相关的数据作为一个对象,这样就可以在程序中计算与现实事物相关的数据。
3.2.3. 对应的配置文件
POM 理念集中体现在 Maven 工程根目录下 pom.xml 这个配置文件中。所以这个 pom.xml 配置文件就是 Maven 工程的核心配置文件。其实学习 Maven 就是学这个文件怎么配置,各个配置有什么用。
3.2.4. pom.xml解读
<!-- 代表当前pom.xml采用的标签结构。从maven2开始就固定是4.0.0 -->
<modelVersion>4.0.0</modelVersion>
...
<!-- 当前工程的坐标信息 -->
<groupId>com.bi</groupId>
<artifactId>wms</artifactId>
<version>1.24.0-SNAPSHOT</version>
...
<!-- 当前工程的打包信息。
jar代表生成jar,
war代表web工程,
pom代表当前工程是用来管理其他工程的 -->
<packaging>jar</packaging>
...
<!-- 在maven中定义属性值。可指定依赖包的版本、java版本、字符集等等 -->
<properties>
<java.version>1.8</java.version>
</properties>
...
<!-- 配置依赖信息,可以包含多个 dependency 子标签
<scope>表示当前依赖的范围
-->
<dependencies>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.1</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
3.3. 约定的目录结构
另外还有一个 target 目录专门存放构建操作输出的结果。
4. 执行 Maven 的构建命令
运行 Maven 中和构建操作相关的命令时,必须进入到 pom.xml 所在的目录。
mvn -v
命令和构建操作无关,只要正确配置了 PATH,在任何目录下执行都可以。而构建相关的命令要在 pom.xml 所在目录下运行——操作哪个工程,就进入这个工程的 pom.xml 目录。
4.1. 清理操作
mvn clean
清理操作。效果:删除 target 目录。
4.2. 编译操作
主程序编译:mvn compile
测试程序编译:mvn test-compile
主体程序编译结果存放的目录:target/classes
测试程序编译结果存放的目录:target/test-classes
4.3. 测试操作
mvn test
测试的报告存放的目录:target/surefire-reports
4.4. 打包操作
mvn package
打包的结果存放的目录:target
4.5. 安装操作
mvn install
安装的效果是将本地构建过程中生成的 jar 包存入 Maven 本地仓库。这个 jar 包在 Maven 仓库中的路径是根据它的坐标生成的。
如下所示,坐标信息如下:
<groupId>com.xxx.maven</groupId>
<artifactId>pro01-maven-java</artifactId>
<version>1.0-SNAPSHOT</version>
在 Maven 仓库中生成的路径如下: D:\0.devEnv\mavenRepository\com\xxx\maven\pro01-maven-java\1.0-SNAPSHOT\pro01-maven-java-1.0-SNAPSHOT.jar
另外,安装操作还会将 pom.xml 文件转换为 XXX.pom 文件一起存入本地仓库,和jar包在同一个目录内,如pro01-maven-java-1.0-SNAPSHOT.pom
。所以我们在 Maven 的本地仓库中想看一个 jar 包原始的 pom.xml 文件时,查看对应 XXX.pom 文件即可,它们是名字发生了改变,本质上是同一个文件。
5. 创建web工程
使用 mvn archetype:generate 命令生成 Web 工程时,需要使用一个专门的 archetype。这个专门生成 Web 工程骨架的 archetype 可以参照官网看到它的用法。
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4
参数 archetypeGroupId
、archetypeArtifactId
、archetypeVersion
用来指定现在使用的 maven-archetype-webapp
的坐标。
生成的pom.xml中,打包方式是war
:<packaging>war</packaging>
查看当前 Web 工程所依赖的 jar 包的列表:mvn dependency:list
[INFO] The following files have been resolved:
[INFO] org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] junit:junit:jar:4.12:test
说明:javax.servlet:javax.servlet-api🫙3.1.0:provided 格式显示的是一个 jar 包的坐标信息。格式是:
groupId : artifactId : 打包方式 : version : 依赖的范围
以树形结构查看当前 Web 工程的依赖信息:mvn dependency:tree
6. 依赖相关
6.1. 依赖范围<scope>
标签的位置:dependencies/dependency/scope
标签的可选值:compile/test/provided/system/runtime/import
默认是compile
compile、test、provided 对比:
main目录(空间) | test目录(空间) | 开发过程(时间) | 部署到服务器(时间) | |
---|---|---|---|---|
compile | 有效 | 有效 | 有效 | 有效 |
test | 无效 | 有效 | 有效 | 无效 |
provided | 有效 | 有效 | 有效 | 无效 |
compile:通常使用的第三方框架的 jar 包这样在项目实际运行时真正要用到的 jar 包都是以 compile 范围进行依赖的。比如 SSM 框架所需jar包。
test:测试过程中使用的 jar 包,以 test 范围依赖进来。比如 junit。
provided:在开发过程中需要用到的“服务器上的 jar 包”通常以 provided 范围依赖进来。比如 servlet-api、jsp-api。而这个范围的 jar 包之所以不参与部署、不放进 war 包,就是避免和服务器上已有的同类 jar 包产生冲突,同时减轻服务器的负担。通过 provided 和 test 范围依赖的jar包不会放入war包。
6.2. 依赖的传递性
在 A 依赖 B,B 依赖 C 的前提下,C 是否能够传递到 A,取决于 B 依赖 C 时使用的依赖范围。
B 依赖 C 时使用 compile 范围:可以传递
B 依赖 C 时使用 test 或 provided 范围:不能传递
所以需要这样的 jar 包时,就必须在需要的地方明确配置依赖才可以。
6.3. 依赖的排除
当 A 依赖 B,B 依赖 C 而且 C 可以传递到 A 的时候,A 不想要 C,需要在 A 的 pom.xml 里,引入 B 的时候,把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。
6.3.1. 配置方式:
如下所示,排除了pro01-maven-java
内的commons-logging
包。
<dependency>
<groupId>com.xxx.maven</groupId>
<artifactId>pro01-maven-java</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
<!-- 使用excludes标签配置依赖的排除 -->
<exclusions>
<!-- 在exclude标签中配置一个具体的排除 -->
<exclusion>
<!-- 指定要排除的依赖的坐标(不需要写version) -->
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
7. Maven工程间的继承
7.1. 概念 & 作用
Maven工程之间,A 工程继承 B 工程时,称 B 工程为父工程,A 为子工程。
本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置。
作用是,在父工程中统一管理项目中的依赖信息,具体来说是管理依赖信息的版本。
它的背景是:
- 对一个比较大型的项目进行了模块拆分。
- 一个
project
下面,创建了很多个module
,每一个module
都需要配置自己的依赖信息。
它背后的需求是:
- 在每一个
module
中各自维护各自的依赖信息很容易发生出入,不易统一管理。 - 使用同一个框架内的不同 jar 包,它们应该是同一个版本,所以整个项目中使用的框架版本需要统一。
- 使用框架时所需要的 jar 包组合(或者说依赖信息组合)需要经过长期摸索和反复调试,最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。
通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包;又能够将以往的经验沉淀下来,节约时间和精力。
比如,下方的代码使用了Spring的多个工程,使用时要求所有 Spring 自己的 jar 包版本必须一致。为了能够对这些 jar 包的版本进行统一管理,我们使用继承这个机制,将所有版本信息统一在父工程中进行管理。
[INFO] +- org.springframework:spring-core:jar:4.0.0.RELEASE:compile
[INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] +- org.springframework:spring-beans:jar:4.0.0.RELEASE:compile
[INFO] +- org.springframework:spring-context:jar:4.0.0.RELEASE:compile
[INFO] +- org.springframework:spring-expression:jar:4.0.0.RELEASE:compile
[INFO] +- org.springframework:spring-aop:jar:4.0.0.RELEASE:compile
[INFO] | \- aopalliance:aopalliance:jar:1.0:compile
注意
父工程的打包方式,要选择pom:<packaging>pom</packaging>
。
只有打包方式为 pom 的 Maven 工程能够管理其他 Maven 工程。打包方式为 pom 的 Maven 工程中不写业务代码,它是专门管理其他 Maven 工程的工程。
7.2. 父子工程的pom.xml
7.2.1. 父工程的pom.xml
<!-- 建了子module后,父工程的 pom.xml中会出现下面的标签 -->
<modules>
<module>pro04-maven-module</module>
<module>pro05-maven-module</module>
<module>pro06-maven-module</module>
</modules>
...
<!-- 使用dependencyManagement标签配置对依赖的管理 -->
<!-- 被管理的依赖并没有真正被引入到工程 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>
提示
上方代码中,每个坐标都要单独维护版本信息,修改起来比较麻烦。可以在<properties>内声明自定义属性统一管理,然后在<version>标签内引用。这样如果要修改版本,只需要修改一处即可。代码如下:
<properties>
<spring.version>4.0.0.RELEASE</spring-boot.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${spring.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
7.2.2. 子工程的pom.xml
<!-- 子工程的pom文件内会出现 <parent> 标签,通过坐标,指向父工程 -->
<parent>
<groupId>com.hpt.maven</groupId>
<artifactId>pro03-maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
...
<!-- 子工程的坐标 -->
<!-- 如果子工程坐标中的groupId和version与父工程一致,那么可以省略 -->
<!-- <groupId>com.hpt.maven</groupId> -->
<artifactId>pro04-maven-module</artifactId>
<!-- <version>1.0-SNAPSHOT</version> -->
...
<!-- 子工程引用父工程中的依赖信息时,可以把版本号去掉。 -->
<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的dependencyManagement来决定。 -->
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
</dependency>
</dependencies>
7.3. 聚合和继承
聚合和继承通常是结合使用的,但是其作用是不同的。
- 继承和聚合,相互独立,二者没有关联; 通常是组合使用的。
- 继承是在子项目中操作,使用
parent
标签,标记xx项目为父项目。 - 聚合是在父项目(pom项目)中操作,使用
modules
标签,将xx项目标记为需要聚合的项目。 - 聚合是将多个模块的工程汇聚到一起,而继承则是指明某个模块工程要继承另一个模块功能。
7.4. 好处
一键执行 Maven 命令:很多构建命令都可以在“总工程”中一键执行。
以
mvn install
命令为例:Maven 要求有父工程时先安装父工程;有依赖的工程时,先安装被依赖的工程。我们自己考虑这些规则会很麻烦。但是工程聚合之后,在总工程执行mvn install
可以一键完成安装,而且会自动按照正确的顺序执行。配置聚合之后,各个模块工程会在总工程中展示一个列表,让项目中的各个模块一目了然。
7.5. 循环依赖问题
如果 A 工程依赖 B 工程,B 工程依赖 C 工程,C 工程又反过来依赖 A 工程,那么在执行构建操作时会报下面的错误:
DANGER
[ERROR] [ERROR] The projects in the reactor contain a cyclic reference:
8. IDEA中maven配置
参考 这里
9. Maven的生命周期
9.1. 三个生命周期
为了让构建过程自动化完成,Maven 设定了三个生命周期,生命周期中的每一个环节对应构建过程中的一个操作。
生命周期名称 | 作用 | 各个环节 |
---|---|---|
Clean | 清理操作相关 | pre-clean clean post-clean |
Site | 生成站点相关 | pre-site site post-site deploy-site |
Default | 主要构建过程 | validate generate-sources process-sources generate-resources process-resources 复制并处理资源文件,至目标目录,准备打包。 compile 编译项目 main 目录下的源代码。 process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources 复制并处理资源文件,至目标测试目录。 test-compile 编译测试源代码。 process-test-classes test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。 prepare-package package 接受编译好的代码,打包成可发布的格式,如JAR。 pre-integration-test integration-test post-integration-test verify install将包安装至本地仓库,以让其它项目依赖。 deploy将最终的包复制到远程的仓库,以让其它开发人员共享;或者部署到服务器上运行(需借助插件,例如:cargo)。 |
9.2. 特点
- 前面三个生命周期彼此是独立的。
- 在任何一个生命周期内部,执行任何一个具体环节的操作,都是从本周期最初的位置开始执行,直到指定的地方。
Maven 之所以这么设计其实就是为了提高构建过程的自动化程度:让使用者只关心最终要干的即可,过程中的各个环节是自动执行的。
10. 插件和目标
10.1. 插件
Maven 的核心程序仅仅负责宏观调度,不做具体工作。具体工作都是由 Maven 插件完成的。例如:编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。
参考:maven插件官网
10.2. 目标
一个插件可以对应多个目标,而每一个目标都和生命周期中的某一个环节对应。
Default 生命周期中有 compile
和 test-compile
两个和编译相关的环节,这两个环节对应 compile
和 test-compile
两个目标,而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。
10.3. 自定义打包的插件maven-assembly-plugin
当我们将项目打包时,希望将项目的说明文档、SQL
脚本文件、项目的配置文件、properties
文件等也打包,此时我们可以通过 Maven
提供的插件 maven-assembly-plugin
进行自定义打包。
在pom.xml
中配置插件依赖
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>make-zip</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<!-- 指定配置文件的路径,路径可变,例如:在resources 目录下则为:src/main/resources/assembly.xml -->
<descriptor>src/main/resources/assembly.xml</descriptor>
</descriptors>
<archiverConfig>
<encoding>utf-8</encoding>
</archiverConfig>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
配置 assembly.xml
<assembly>
<!-- 打包文件名的标识符,在打包后的文件名称的后缀显示 -->
<id>release</id>
<formats>
<!-- 这里设置打包的类型,例如 tar、zip 等 -->
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<!-- 将 jar 包从项目所在的目录中的 target 目录取出来,放到 zip 包-->
<fileSet>
<directory>target</directory>
<includes>
<include>${project.artifactId}-${project.version}.jar</include>
</includes>
<outputDirectory>/${project.artifactId}</outputDirectory>
</fileSet>
<!-- 将 application.yml 从项目所在的目录中的 class 目录取出来,放到 zip 包-->
<fileSet>
<directory>${project.build.directory}/classes</directory>
<includes>
<include>application.yml</include>
</includes>
<outputDirectory>/${project.artifactId}</outputDirectory>
</fileSet>
<!-- 将 scripts 目录中所有文件取出,只排除 run 目录,放到 zip 包的 scripts 目录下-->
<fileSet>
<directory>scripts</directory>
<includes>
<include>**</include>
</includes>
<excludes>
<exclude>run</exclude>
</excludes>
<outputDirectory>/${project.artifactId}/scripts</outputDirectory>
</fileSet>
<fileSet>
<directory>./</directory>
<includes>
<include>readme.md</include>
</includes>
<outputDirectory>/${project.artifactId}</outputDirectory>
</fileSet>
</fileSets>
</assembly>
执行 mvn install
,即可打包成功
11. 项目中遇到/用到过的插件
11.1. maven-compiler-plugin
maven编译插件。配置中可以指定编译时的java版本、编码。
使用示例:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<java.version>1.8</java.version>
</properties>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<encoding>${project.build.sourceEncoding}</encoding>
</configuration>
</plugin>
11.2. maven-dependency-plugin
11.3. maven-jar-plugin
maven官方插件,该插件提供了构建 jar 的功能。主要目标为:jar:jar
遇到的用法,见下方spring-boot-maven-plugin
插件中的示例。此次也只分析这3个属性,其他属性含义见官网。
<addClasspath>
:是否要在META-INF/MANIFEST.MF
文件中创建Class-Path属性(描述依赖项列表)。默认值是false。<classpathPrefix>
:addClasspath
为true时才有意义,含义是指定第三方jar的路径前缀。默认值是“”。可以指定最终输出jar的META-INFO/MANIFEST文件中,Class-Path属性的前缀。如果想给最终的jar瘦身,即把第三方依赖从最终jar中移除,则这项必须写,用来指定jar的依赖路径的前缀。Class-Path: 依赖项列表,若存在多个依赖项时则采用空格分隔。依赖项路径为以JAR包路径为参考系的相对路径, 有个小细节就是, 如果自己生成这个文件,在引用了所有的以来后, 后面还有一个 '.'
<useUniqueVersions>
: 是否使用唯一时间戳快照版本而不是 -SNAPSHOT 版本,默认值为true
。如果为true会在使用时生成很多以时间戳结尾的jar,如果其他地方依赖了这个jar,使用时会报错。
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<useUniqueVersions>false</useUniqueVersions>
</manifest>
11.4. spring-boot-maven-plugin
spring boot提供的maven打包插件,可打直接可运行的jar包或war包。官方文档地址
使用2.2.1.RELEASE版本需要maven版本在2.0及以上,JDK在1.8及以上。
一般对使用
spring-boot-maven-plugin
插件打出的可执行jar不建议作为jar给其他服务引用,因为可能出现访问可执行jar中的一些配置文件找不到的问题。如果想让构建出来的原始jar不被重新打包,可以对spring-boot-maven-plugin插件配置classifier属性,自定义一个可运行jar名称,这样该插件就不会对原始的jar重命名操作了。
11.4.1. 目标概述
- spring-boot:run:运行你的 Spring Boot 应用程序。
- spring-boot:repackage:把你的jar/war重新打包为可执行的jar/war包。
- spring-boot:start/stop:来管理 Spring Boot 应用程序的生命周期(即用于集成测试)。
- spring-boot:build-info:生成可供执行器使用的构建信息。
此处只分析遇到的用的最多的目标:repackage。
11.4.2. repackage目标(默认goal)
作用:重新打包现有的 JAR 和 WAR 存档,以便它们可以 使用 java -jar 从命令行执行。使用此目标后,默认情况下,maven自己先打的包会被加上
.origin
后缀。这是不可执行的jar,用来被其他项目引用。<configuration>
用来对这个插件进行配置。在最下方的例子中,设置了主启动类,并引入了null,即最终包中不包含任何第三方依赖的jar。如果要排除某个jar,可以使用类似这样的方式:<excludes> <exclude> <groupId>com.foo</groupId> <artifactId>bar</artifactId> </exclude> </excludes>
也可以使用
<excludeGroupIds>com.foo</excludeGroupIds>
,来排除这个group下的所有jar。<layout>ZIP</layout>
:实现将/lib外置需要的配置。<outputDirectory>
:指定该插件打的包最终会放到这个属性对应的路径下。如果未指定,默认路径是${project.build.directory}
。<mainClass>
:指定主启动类。如果没有指定,会查找包内第一个含有main()
方法的类作为启动类。
使用示例:
下方的实例中使用了2个插件。
maven-jar-plugin
中指定了依赖的第三方jar要放到lib目录,spring-boot-maven-plugin
插件中排除了第三方jar,并把最终输出的jar包放在了指定位置。这样会大大减少最终jar包的体积,实现jar包“瘦身”的效果。在我们的实际应用中,会去${boot-jar-output}
目录下再重新打包成docker镜像。
<!-- 基于maven-jar-plugin插件实现把依赖jar定义写入输出jar的META-INFO/MANIFEST文件;必须写在 spring-boot-maven-plugin 之前,才能确保下面的插件后执行 -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<useUniqueVersions>false</useUniqueVersions>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.3.7.RELEASE</version>
<configuration>
<!-- 指定主启动类 -->
<mainClass>com.cisai.tech.byqanalyseserver.ByqAnalyseServerApplication</mainClass>
<includes>
<!-- 不存在的include引用,相当于排除所有maven依赖jar,没有任何三方jar文件会打入最终输出的jar中。用来减少jar的体积。 -->
<include>
<groupId>null</groupId>
<artifactId>null</artifactId>
</include>
</includes>
<layout>ZIP</layout>
<!--
基于maven-jar-plugin输出微服务jar文件进行二次spring boot重新打包文件的输出目录
所有微服务构建输出jar文件统一输出到与lib同一个目录,便于共同引用同一个lib目录
-->
<outputDirectory>${boot-jar-output}</outputDirectory>
</configuration>
<executions>
<execution>
<id>repackage</id>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
- 0很棒
- 0不错
- 0一般
- 0???