解决SpringCloud下spring-boot-maven-plugin插件的打包问题
一、Maven生命周期、阶段、目标
二、SpringCloud下spring-boot-maven-plugin插件的打包的问题
三、SpringCloud正确的打包方式
一、Maven生命周期、阶段、目标 之前一直对Maven的3套生命周期有点不清楚，记录下自己的理解。
生命周期，就是一个事物从初始到消亡、开始到结束的过程，而Maven的生命周期就是指Maven官方对项目执行Maven构建从开始使用到使用结束整个流程的定义。
而所说的Mavn有3套生命周期，就是指Maven从开始使用到使用结束要经过3个生命周期的流程，这3个生命周期各自独立的，依次经过的生命周期分别是 clean、default、site，每个生命周期流程中也包含了不同的 phase（或者称作阶段），这些阶段也是有先后顺序的。可以说3套生命周期就是对这些阶段做的一个逻辑上划分、分类。
clean生命周期：因为项目如果是已经有部署过的话，我们肯定是要先把已经编译生成好的文件，要先清除掉。
default生命周期：然后执行一些测试、编译等步骤，default才是我们的重点，也是包含了最多的阶段。
site生命周期：最终发布到服务器上。
这样最终就形成了3套生命周期。当然以上的生命周期、阶段其实都是Maven官方自己所定义的一些逻辑上Maven项目应该经过的流程，并不一定每个项目都会经过这些所有的流程。而且用户可以通过自定义插件的方式，来将插件绑定到各个阶段，当我们在Maven执行命令的时候，就会执行自定义的特殊业务。
比如对于spring-boot-maven-plugin，这个插件，我们使用这个插件的时候可以自定义该插件的phase为pre-clean。
mvn执行阶段的命令格式是：mvn 阶段1 [阶段2] [阶段n]。那么当执行mvn pre-clean命令，就会执行pre-clean阶段的流程，该流程在maven官方应该是没有执行任务逻辑的。我们可以对比下对一个项目执行pre-clean和clean的差别：只有clean的时候才多了实执行的delete的操作。
但是我们设置了这个<phase>pre-clean</phase>绑定后，我们执行pre-clean命令，自然就会执行到spring-boot-maven-plugin这个插件的逻辑。这里只是为了演示有绑定了pre-clean阶段的动作，实际项目上是不应该绑定到pre-clean阶段上的。
并且在一个阶段上也可以指定不同的goal/目标（可以称之为这个插件所提供的功能），一个插件可以提供多种不同的goal/目标/功能，在IDEA的Maven控制面板上打开该pom项目，可以看到这个spring-boot插件就是包含了这些目标：build-info、help、repackage、run、start、stop。
而我们上面配置了<goal>repackage</goal>，意味着在执行pre-clean阶段的时候，会实际执行到该插件的repackage这个目标。可以看到执行mvn pre-clean的结果，这个就是执行了repackage目标。在执行mvn命令可以指定要执行的目标，所以上面相当于执行了：mvn pre-clean:repackage
在clean这个生命周期中，Maven总共定义了三个阶段，分别是：pre-clean、clean、post-clean，各个阶段有先后顺序，执行某个阶段的时候会有序执行其前面的所有阶段。比如执行mvn post-clean，则依次执行pre-clean、clean、post-clean。可以看到当我们执行mvn post-clean的时候，也会出现了上面那样pre-clean时的错误
当我们在使用该插件的时候，没有定义phase的话，会自动使用其插件定义的时候用的defaultPhase。比如我们使用的spring-boot-maven-plugin没有配置phase，则默认的phase是插件源码RepackageMojo在@Mojo定义的参数defaultPhase，也就是package阶段了。所以我们只要增加了goal的配置，即使没有配置pahse，也可以在package阶段直接打包了
在SpringCloud项目中的spring-boot-maven-plugin配置如下：
当我们直接在SpringCloud项目下，对各个微服务子项目直接用命令mvn clean package打包会发现最终打出来的jar包并非可执行jar包，而只是我们项目源文件的普通jar包。
正确的打包命令应该是mvn clean package spring-boot:repackage，打包结果如下图。其中.original结尾的文件，就是项目源代码最初的jar包，然后springboot打包插件再根据该jar包再生成最终的可执行jar包。
为什么SpringCloud工程打可执行jar的命令是：mvn clean package spring-boot:repackage，而那些继承了spring-boot-starter-parent的项目可以直接通过mvn clean package就可以打可执行jar包？
这是因为在spring-boot-starter-parent的项目里已经帮我们将打包插件绑定到了repackage的目标，而该插件如上文所提到的，已经默认绑定到了package的阶段，所以当我们在SpringBoot项目执行mvn clean package的时候其实就自动执行了打普通jar包、并且通过repackage最终打成可执行jar包的流程。
所以如果我们的SpringCloud想要也能够像SpringBoot那样执行打包命令的话，可以在SpringCloud的父pom工程也定义好plugin的repackage目标：
这样在子工程执行package后，就可以发现已经可以自动执行打普通jar包的目标了，接着继续执行repackage目标，最终就是我们所要的可执行jar包。
如果只是单独执行mvn spring-boot:repackage，会报错：Source file must be provided。需要先package 与 spring-boot:repackage 在同一条命令执行才正确，可能插件内部是在通过本次命令执行中，根据package打出来的普通jar包的基础上进行repackage的，不会去获取仓库中已有的普通jar包。
到此这篇关于SpringCloud下spring-boot-maven-plugin插件的打包问题的文章就介绍到这了,更多相关spring-boot-maven-plugin插件打包内容请搜索软件开发网以前的文章或继续浏览下面的相关文章希望大家以后多多支持软件开发网！
