背景

一个多模块项目，一级子模块就有7个，一部分模块还有自己的子模块，包含了纯pom，jar的各种模块。
主要的子模块是 SpringBoot项目, 需要打包成一个可执行jar。

目标

WHAT 主要：使得项目易于构建部署，适应不同场景下的复杂工程的组织、发行、交付、落地中的问题。

HOW 方法：学习大型开源项目的打包方式（发行、组织），以及学习多种打包插件。

WHERE 应用场景实践：多场景部署，优化部署流程，减少不必要的构建和文件复制传输。

从现象寻找优化点

开发、测试环境中，经常改动的只有个别几个模块，有的时候甚至只有一个，需要一种能实现类似于增量编译、热部署的方式，加快流程速度。

已知有spring-boot-devtools可以在本地IDE开发环境中做到热部署，而实际上有的项目在本地无法完整启动，例如运维使用了防火墙限制了ZooKeeper的连接，数据库的连接。

比较影响开发体验。

于是把变化的和不变化的分开看待，分别打包部署，会灵活方便许多。

结构分析

封装格式

很多开源软件目录结构都是类似的，bin,lib,conf,pluginmaven子项目依赖打包等等，这个可以通过maven-assembly-plugin实现，那么打包出来的是一个zip。

依赖

有三类，一种是其他模块编译出来的，通常会打包出 xxxx.jar，通过 dependency 像第三方依赖一样引入。
第二类是私服里面，其他项目，或者其他团队发行的 xxxx.jar。
第三类就是中央仓库的，第三方jar包。

分门别类

为了便于描述，假设该项目名字叫 slankka-application

依赖组织方式

如果只用 springboot-maven-plugin 打包，是比较常见的做法，这种方式打出来的jar 一般很大，当项目足够复杂，可能打出来的几百兆以上。

如果只用，或者，则缺少了的优点。

解决办法是多种插件结合使用，在不同阶段使用不同的插件。

插件功能一览

应用细节

对于开发环境，maven-dependency-plugin，maven-assembly-plugin 构建过程，可以用 profile 做成可选：

例： 仅linux服务器需要打包成ZIP，Windows, Mac电脑不需要。

只有第一次打包上传到服务器时，才需要一个完整的ZIP。

快速迭代

对于日常开发，敏捷开发等，只需要前面三个插件。

(实践： 将原本200MB的jar （fat-jar或者ZIP）缩减成2MB左右。这样直接发布到服务器上，很快。)

3rd-party 和 子模块的依赖分开

对于子模块的迭代，单独打包（假如不用shade方式和springboot的jar放在一起），则会被maven-dependency-plugin复制到lib，和第三方jar混在一起，有时候会忘记替换，造成失误，不如按照半导体芯片领域模块化思维，直接集成到一个jar，那么就使用shade 把子模块的artifact压缩到一起，这样的好处就是，lib下，完全可以称之为 3rdParty，这部分几乎不会有变动。即便有的话，来一次完整的构建即可。

推荐使用shade插件将其他子模块和应用程序启动模块作为整体

shade的好处是，将子模块的字节码classes 和springboot应用所在模块放在同样的位置。
相比而言，spring-boot-maven-plugin 会放进 META-INF/lib内，这个非常适合其他项目的lib，作为整体嵌入这个jar。

弄清楚这些目标以后，就知道插件的include和exclude怎么写了。

插件负责的范围

附录

以下配置，均在 slankka-server/pom.xml 内，最外层 slankka-application/pom.xml 是一个pom。

根据情况，有些放在build内，有些可放在 profile.build内。

maven-shade-plugin 的配置

spring-boot-maven-plugin的打包配置

如果没有要携带的其他项目依赖，则直接include里面写 none:none

maven-dependency-plugin的打包配置

maven-assembly-plugin的配置

略

maven-jar-plugin 的配置

略

今天的文章
maven子项目依赖打包分享到此就结束了，感谢您的阅读。