我要评论一 spring-boot-maven-plugin 插件的5个goals
spring-boot:repackage，默认goal。在mvn package之后，再次打包可执行的jar/war，同时保留mvn package生成的jar/war为.origin；重新打包存在的jar或者war包从而使他们可以在命令行使用jar -jar来执行，使用layout=none也可以简单的打包有嵌套依赖的jar(没有主类，所以无法执行)；它可以替代常规的构件或者连接到构建生命周期并有独立的分级。
spring-boot:run，运行spring boot应用
spring-boot:start，在mvn integration-test阶段，进行spring boot应用生命周期的管理；启动spring应用程序。和run目标不同，该目标不会阻塞，并且允许其他目标来操作应用程序。这个目标通常是在应用程序集成测试套件开始之前和停止之后的继承测试脚本中使用；集成spring boot应用程序到集成测试阶段，从而使应用程序在集成测试程序之前启动
spring-boot:stop，在mvn integration-test阶段，进行spring boot应用生命周期的管理；停止使用start目标启动的spring应用程序，通常在测试套件完成后被调用。；集成spring boot应用程序到集成测试阶段，从而使应用程序在集成测试程序之前启动
spring-boot:build-info，生成actuator使用的构建信息文件build-info.properties
2. 配置pom.xml文件
<build>
<plugins>
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.5.4.release</version>
</plugin>
</plugins>
</build>二 应用场景
1 重新打包应用
为了重新打包应用，只需要在pom文件中的plugin配置中如下：
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>2 运行应用程序
插件包含了一个run目标，该目标能够从命令行执行应用程序: mvn spring-boot:run
默认情况下，应用从maven的jvm运行。如果需要在分支中运行，则指定fork选项。如果指定了jvmarguments或者agent参数，分支进程也会执行。
如果需要制定某些jvm参数(如为了debug)，可以使用jvmarguments参数，更多细节参考 调试应用 一章。方便起见，为了启用总则(profiles)，可以使用特定(profiles)属性来处理，参考 指定使用的配置文件 一章。
spring boot 1.3已经推出了devtools，它是提升使用spring boot应用开发时经验的一个模块。启用该模块，仅仅在项目中添加如下配置即可：
org.springframework.boot spring-boot-devtools 1.3.0.build-snapshot true
目前最新是2.0.0.build-snapshot了。
当devtools运行时，会在重新编译应用时进行检测变化并且自动刷新。这不仅包括资源文件，也包括代码。它也提供了一个激活的可以重加在的服务器，所以不管任何改变都会自动出发浏览器刷新。
devtools也可配置成仅仅静态资源改变时刷新浏览器(也就是忽略代码的改变)，仅仅增加如下配置：
spring.devtools.remote.restart.enabled=false
在devtools之前，该插件已经默认支持资源的及时刷新(hot refreshing)，为了支持devtools功能，该插件功能已经被禁用。但是可以随时恢复该功能，恢复功能配置如下；
<build>
……
<plugins>
……
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<configuration>
<addresources>true</addresources>
</configuration>
</plugin>
……
</plugins>
……
</build>当启用addresources配置时，任意src/main/resources文件夹在应用运行时将被添加到应用的类路径，同时任意target/class中发现重复的资源将被移除。这将在发布web应用时使资源及时刷新非常有用。例如，当使用html，css和javascript文件时，不用重新编译应用就可以立马看到变化。这对前端开发人员不用下载安装java ide就可以工作也是一种非常有用的方式。
需要注意的是，该特性的副作用是在构建时资源过滤不起作用
为了与repackage目标保持一致，run目标在构件类路径下文件时将排除在配置依赖时排除的依赖配置。更详细的的请参考 排除一个依赖 章节。
有时候在运行应用时包含测试依赖也是非常有用的。例如，在测试模式下使用根目录类运行应用。如果希望这样做，可以设置usetestclasspath参数的值为true。注意：尽在运行应用时生效：重新打包目标将不会增加测试依赖到结果jar和war包中。
3 使用集成测试
虽然可以很容易从测试(测试套件)本身启动spring boot程序，但可能需要在构建自身来处理。为了确信围绕集成测试的spring boot应用的生命周期被合适的管理，可以使用start和stop目标。如下配置：
<build>
……
<plugins>
……
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<executions>
<execution>
<id>pre-integration-test</id>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>post-integration-test</id>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
……
</plugins>
……
</build>这样的设置现在可以使用failsafe-plugin来运行你的集成测试，正如你所期待的哪样。
更多详细细节，参 考随机端口的集成测试的。
4 自定义分类重打包
默认情况下，repackage目标将使用可执行的构件来替代原始的构件。如果希望保留原是构件，并且也使用不同的分类来附属保留可执行的构件，可以配置如下：
说明：如果不适用repackage目标，那么maven执行package命令生成的jar包只有一个，名称为pom.xml里面配置的name(artifactid)-version.jar
如果加入了repackage配置，则maven打包生成的jar包会被重命名为name-version.jar.original,使用repackage重新打包生成的jar包名称为name-version.jar,
下面的配置就是如果希望保留原始构件生成的jar包名称不变，同时也想保留repackage打包生成的jar包，可以自定义命名。
<project>
<build>
<plugins>
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>exec</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>如上配置，那么使用repackage重新生成的包的名称就是name-version-exec.jar,就是在version后面追加了configuration节点中的classifier节点中的值，该值是自定义的。但是如果classifier节点中什么值都不写，那么就和默认的repackage配置一样，即原始的构件为name-version.jar.original,repackage打包的jar为name-version.jar
5 排除依赖
默认情况下，repackage和run目标都会包含所有provided scope的依赖。基于boot的项目应该考虑provided scope的依赖就像容器所需要的依赖包来使应用可以运行。
**有三种方式可以排除运行时被打包使用的依赖
1、通过指定groupid和artifactid来排除依赖(如果需要可以指定classifier，这是可选的)
2、通过指定artifactid，来排除所有匹配的依赖
3、通过指定groupid，来排除所有属于该group的依赖
如下通过指定groupid和artifactid排除依赖 **
<project>
<build>
<plugins>
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<configuration>
<excludes>
<exclude>
<groupid>com.foo</groupid>
<artifactid>bar</artifactid>
</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
</project>如上配置就会排除对com.foo:bar的jar包
如下通过指定artifactid，来排除artifactid与此匹配的所有依赖
<project>
<build>
<plugins>
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<configuration>
<excludeartifactids>my-lib,another-lib</excludeartifactids>
</configuration>
</plugin>
</plugins>
</build>
</project>如上配置就会排除所有artifactid为my-lib和another-lib的jar包
如下通过指定groupid，来排除groupid与此匹配的所有依赖
<project>
<build>
<plugins>
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<configuration>
<excludegroupids>com.foo</excludegroupids>
</configuration>
</plugin>
</plugins>
</build>
</project>如上配置则排除掉所有groupid为com.foo的jar包
###6 调试应用
默认情况下，run目标和mvn命令是在同一个进程中执行的，除非jvm参数或者客户端明确指定。可以通过使用fork属性明确的开启或者关闭是否在同一进程中执行。
如果需要fork这个进程并且进行调试，可以添加需要的jvm参数来开启远程调试。如下配置为挂起进程，直到有调试请求从5005端口进入。
<project>
<build>
<plugins>
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<configuration>
<jvmarguments>
-xdebug -xrunjdwp:transport=dt_sorket,server=y,suspend=y,address=5005
</jvmarguments>
</configuration>
</plugin>
</plugins>
</build>
</project>需要注意的是，只要你指定了这些jvm参数，这个进程就会自动被fork。这些jvm擦书也可以在命令行中指定，确认书写正确：
mvn spring-boot:run -drun.jvmarguments=“-xdebug -xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005”
7 集成测试的随机端口
spring boot集成测试的一个好特性是它能够为web应用分配一个空闲端口。当start目标插件使用时，spring boot应用是被分离执行的，这让传递给集成测试程序本身实际的端口变得非常困难。
如下的配置展示如何使用build-help-plugin插件达到相同的特性。
<project>
<build>
<plugins>
<plugin>
<groupid>org.codehaus.mojo</groupid>
<artifactid>build-helper-maven-plugin</artifactid>
<executions>
<execution>
<id>reserve-tomcat-port</id>
<goals>
<goal>reserve-network-port</goal>
</goals>
<phase>process-resources</phase>
<configuration>
<portnames>
<portname>tomcat.http.port</portname>
</portnames>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<executions>
<execution>
<id>pre-integration-test</id>
<goals>
<goal>start</goal>
</goals>
<configuration>
<arguments>
<argument>--server.port={tomcat.http.port}
</test.server.port>
</systempropertyvariables>
</configuration>
</plugin>
</plugins>
</build>现在可以在任意的集成测试中查询test.server.port系统属性来给server创建一个合适的url。
8 指定使用的配置文件
一个特定应用使用的配置文件可以通过profiles参数指定。如下配置启动了foo和bar两个配置文件：
<project>
<build>
<plugins>
<plugin>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-maven-plugin</artifactid>
<version>1.3.0.build-snapshot</version>
<configuration>
<profiles>
<profile>foo</profile>
<profile>bar</profile>
</profiles>
</configuration>
</plugin>
</plugins>
</build>
</project>使用哪个配置文件也可以通过命令行参数配置，如果有多个，需要使用都好将他们隔开：
mvn spring-boot:run -drun.profiles=bar,foo
到此这篇关于spring boot spring-boot-maven-plugin 参数配置详解的文章就介绍到这了,更多相关springboot spring-boot-maven-plugin 参数配置内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论