解决SpringCloud下spring-boot-maven-plugin插件的打包问题

目录

• 一、Maven生命周期、阶段、目标   www.devze.com;      
•  二、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的结果，这个就是执行了rBrHWiTYqepackage目标。在执行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项目中的spring-boot-maven-plugin配置如下：

         当我们直接在SpringCloud项目下，对各个微服务子项目直接用命令mvn clean package打包会发现最终打出来的jar包并非可执行jar包，而只是我们项目源文件的普通jar包。

         正确的打包命令应该是mvn clean package spring-boot:repackage，打包结果如下图。其中.original结尾的文件，就是项目源代码最初的jar包，然后springboot打包插件再根据该jar包再生成最终的可执行jar包。

三、SpringCloud正确的打包方式

        为什么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目标：

     &BrHWiTYqnbsp;   这样在子工程执行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插件打包内容请搜索我们以前python的文章或继续浏览下面的相关文章希望大家以后多多支持我们！