Stephane Nicoll
6 years ago
19 changed files with 5 additions and 1252 deletions
@ -1,56 +0,0 @@
@@ -1,56 +0,0 @@
|
||||
----- |
||||
Generate build information |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2016-03-17 |
||||
----- |
||||
|
||||
Spring Boot Actuator displays build-related information if a <<<META-INF/build-info.properties>>> |
||||
file is present. The <<<build-info>>> goal generates such file with the coordinates of the project |
||||
and the build time. It also allows you to add an arbitrary number of additional properties: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<goals> |
||||
<goal>build-info</goal> |
||||
</goals> |
||||
<configuration> |
||||
<additionalProperties> |
||||
<encoding.source>UTF-8</encoding.source> |
||||
<encoding.reporting>UTF-8</encoding.reporting> |
||||
<java.source>${maven.compiler.source}</java.source> |
||||
<java.target>${maven.compiler.target}</java.target> |
||||
</additionalProperties> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
This configuration will generate a <<<build-info.properties>>> at the expected location with |
||||
four additional keys. Note that <<<maven.compiler.source>>> and <<<maven.compiler.target>>> |
||||
are expected to be regular properties available in the project. They will be interpolated as |
||||
you would expect. |
||||
|
||||
|
||||
|
||||
|
||||
@ -1,59 +0,0 @@
@@ -1,59 +0,0 @@
|
||||
----- |
||||
Use a custom layout |
||||
----- |
||||
Dave Syer |
||||
----- |
||||
2016-10-30 |
||||
----- |
||||
|
||||
Spring Boot repackages the jar file for this project using a custom layout factory |
||||
defined in the additional jar file, provided as a dependency to the build plugin: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<id>repackage</id> |
||||
<goals> |
||||
<goal>repackage</goal> |
||||
</goals> |
||||
<configuration> |
||||
<layoutFactory implementation="com.example.CustomLayoutFactory"> |
||||
<customProperty>value</customProperty> |
||||
</layoutFactory> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
<dependencies> |
||||
<dependency> |
||||
<groupId>com.example</groupId> |
||||
<artifactId>custom-layout</artifactId> |
||||
<version>0.0.1.BUILD-SNAPSHOT</version> |
||||
</dependency> |
||||
</dependencies> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
The layout factory is provided as an implementation of <<<LayoutFactory>>> (from |
||||
spring-boot-loader-tools) explicitly specified in the pom. If there is only one custom |
||||
<<<LayoutFactory>>> on the plugin classpath and it is listed in |
||||
<<<META-INF/spring.factories>>> then it is unnecessary to explicitly set it in the |
||||
plugin configuration. |
||||
|
||||
Layout factories are always ignored if an explicit <<layout>> is set. |
||||
@ -1,84 +0,0 @@
@@ -1,84 +0,0 @@
|
||||
----- |
||||
Exclude a dependency |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2014-05-06 |
||||
----- |
||||
|
||||
By default, both the <<<repackage>>> and the <<<run>>> goals will include any <<<provided>>> |
||||
dependencies that are defined in the project. A Spring Boot project should consider |
||||
<<<provided>>> dependencies as <<container>> dependencies that are required to run |
||||
the application. |
||||
|
||||
Some of these dependencies may not be required at all and should be excluded from the |
||||
executable jar. For consistency, they should not be present either when running the |
||||
application. |
||||
|
||||
There are two ways one can exclude a dependency from being packaged/used at runtime |
||||
|
||||
* Exclude a specific artifact identified by <<<groupId>>> and <<<artifactId>>> |
||||
(optionally with a <<<classifier>>> if needed) |
||||
|
||||
* Exclude any artifact belonging to a given <<<groupId>>> |
||||
|
||||
[] |
||||
|
||||
The following excludes <<<com.foo:bar>>> (and only that artifact) |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<configuration> |
||||
<excludes> |
||||
<exclude> |
||||
<groupId>com.foo</groupId> |
||||
<artifactId>bar</artifactId> |
||||
</exclude> |
||||
</excludes> |
||||
</configuration> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
This example excludes any artifact belonging to the <<<com.foo>>> group |
||||
|
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<configuration> |
||||
<excludeGroupIds>com.foo</excludeGroupIds> |
||||
</configuration> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
@ -1,82 +0,0 @@
@@ -1,82 +0,0 @@
|
||||
----- |
||||
Random port for integration tests |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2015-04-16 |
||||
----- |
||||
|
||||
One nice feature of the Spring Boot test integration is that it can allocate a free |
||||
port for the web application. When the <<<start>>> goal of the plugin is used, the |
||||
Spring Boot application is started separately, making it difficult to pass the actual |
||||
port to the integration test itself. |
||||
|
||||
The example below showcases how you could achieve the same feature using the |
||||
{{{https://www.mojohaus.org/build-helper-maven-plugin/}build-helper-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>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<id>pre-integration-test</id> |
||||
<goals> |
||||
<goal>start</goal> |
||||
</goals> |
||||
<configuration> |
||||
<arguments> |
||||
<argument>--server.port=${tomcat.http.port}</argument> |
||||
</arguments> |
||||
</configuration> |
||||
</execution> |
||||
<execution> |
||||
<id>post-integration-test</id> |
||||
<goals> |
||||
<goal>stop</goal> |
||||
</goals> |
||||
</execution> |
||||
</executions> |
||||
</plugin> |
||||
<plugin> |
||||
<groupId>org.apache.maven.plugins</groupId> |
||||
<artifactId>maven-failsafe-plugin</artifactId> |
||||
<configuration> |
||||
<systemPropertyVariables> |
||||
<test.server.port>${tomcat.http.port}</test.server.port> |
||||
</systemPropertyVariables> |
||||
</configuration> |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
--- |
||||
|
||||
You can now retrieve the <<<test.server.port>>> system property in any of your integration test |
||||
to create a proper <<<URL>>> to the server. |
||||
@ -1,63 +0,0 @@
@@ -1,63 +0,0 @@
|
||||
----- |
||||
Skip integration tests |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2016-11-25 |
||||
----- |
||||
|
||||
The <<<skip>>> property allows to skip the execution of the Spring Boot maven plugin |
||||
altogether. This example shows how you can skip integration tests with a command-line |
||||
property and still make sure that the <<repackage>> goal runs: |
||||
|
||||
--- |
||||
<project> |
||||
<properties> |
||||
<skip.it>false</skip.it> |
||||
... |
||||
</properties> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<id>pre-integration-test</id> |
||||
<goals> |
||||
<goal>start</goal> |
||||
</goals> |
||||
<configuration> |
||||
<skip>${skip.it}</skip> |
||||
</configuration> |
||||
</execution> |
||||
<execution> |
||||
<id>post-integration-test</id> |
||||
<goals> |
||||
<goal>stop</goal> |
||||
</goals> |
||||
<configuration> |
||||
<skip>${skip.it}</skip> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
</plugin> |
||||
<plugin> |
||||
<groupId>org.apache.maven.plugins</groupId> |
||||
<artifactId>maven-failsafe-plugin</artifactId> |
||||
<configuration> |
||||
<skip>${skip.it}</skip> |
||||
</configuration> |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
--- |
||||
|
||||
By default, the integration tests will run but this setup allows you to easily disable |
||||
them on the command-line as follows: <<<mvn verify -Dskip.it=true>>>. |
||||
@ -1,187 +0,0 @@
@@ -1,187 +0,0 @@
|
||||
----- |
||||
Repackage classifier |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2014-05-02 |
||||
----- |
||||
|
||||
By default, the <<<repackage>>> goal will replace the original artifact with the |
||||
repackaged one. That's a sane behavior for modules that represent an app but if |
||||
your module is used as a dependency of another module, you need to provide a |
||||
classifier for the repackaged one. |
||||
|
||||
The reason for that is that application classes are packaged in <<<BOOT-INF/classes>>> |
||||
so that the dependent module cannot load a repackaged jar's classes. If that is the |
||||
case or if you prefer to keep the original artifact and attach the repackaged one |
||||
with a different classifier, configure the plugin as follows: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<id>repackage</id> |
||||
<goals> |
||||
<goal>repackage</goal> |
||||
</goals> |
||||
<configuration> |
||||
<classifier>exec</classifier> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
If you are using `spring-boot-starter-parent`, the `repackage` goal is executed |
||||
automatically in an execution with id `repackage`. In that setup, only the configuration |
||||
should be specified as shown in the following example: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<executions> |
||||
<execution> |
||||
<id>repackage</id> |
||||
<configuration> |
||||
<classifier>exec</classifier> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
This configuration will generate two artifacts: the original one and the repackaged |
||||
counter part produced by the repackage goal. Both will be installed/deployed |
||||
transparently. |
||||
|
||||
You can also use the same configuration if you want to repackage a secondary artifact |
||||
the same way the main artifact is replaced. The following configuration installs/deploys |
||||
a single <<<task>>> classified artifact with the repackaged app: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>org.apache.maven.plugins</groupId> |
||||
<artifactId>maven-jar-plugin</artifactId> |
||||
<version>@maven-jar-plugin.version@</version> |
||||
<executions> |
||||
<execution> |
||||
<goals> |
||||
<goal>jar</goal> |
||||
</goals> |
||||
<phase>package</phase> |
||||
<configuration> |
||||
<classifier>task</classifier> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
</plugin> |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<id>repackage</id> |
||||
<goals> |
||||
<goal>repackage</goal> |
||||
</goals> |
||||
<configuration> |
||||
<classifier>task</classifier> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
As both the <<<maven-jar-plugin>>> and the <<<spring-boot-maven-plugin>>> runs at the |
||||
same phase, it is important that the jar plugin is defined first (so that it runs before |
||||
the repackage goal). |
||||
|
||||
Again, if you are using `spring-boot-starter-parent`, this can be simplified as follows: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>org.apache.maven.plugins</groupId> |
||||
<artifactId>maven-jar-plugin</artifactId> |
||||
<executions> |
||||
<execution> |
||||
<id>default-jar</id> |
||||
<configuration> |
||||
<classifier>task</classifier> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
</plugin> |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<executions> |
||||
<execution> |
||||
<id>repackage</id> |
||||
<configuration> |
||||
<classifier>task</classifier> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
|
||||
|
||||
|
||||
@ -1,50 +0,0 @@
@@ -1,50 +0,0 @@
|
||||
----- |
||||
Local repackaged artifact |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2016-03-01 |
||||
----- |
||||
|
||||
By default, the <<<repackage>>> goal will replace the original artifact with the |
||||
executable one. If you need to only deploy the original jar and yet be able to |
||||
run your app with the regular file name, configure the plugin as follows: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<id>repackage</id> |
||||
<goals> |
||||
<goal>repackage</goal> |
||||
</goals> |
||||
<configuration> |
||||
<attach>false</attach> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
This configuration will generate two artifacts: the original one and the executable counter |
||||
part produced by the repackage goal. Only the original one will be installed/deployed. |
||||
|
||||
|
||||
|
||||
|
||||
@ -1,42 +0,0 @@
@@ -1,42 +0,0 @@
|
||||
----- |
||||
Repackage classifier |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2019-03-29 |
||||
----- |
||||
|
||||
If you need the repackaged jar to have a different local name than the one defined by |
||||
the <<<artifactId>>> attribute of the project, simply use the standard <<<finalName>>> |
||||
as shown in the following example: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
<finalName>my-app</finalName> |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<id>repackage</id> |
||||
<goals> |
||||
<goal>repackage</goal> |
||||
</goals> |
||||
</execution> |
||||
</executions> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
This configuration will generate the repackaged artifact in <<<target/my-app.jar>>>. |
||||
@ -1,47 +0,0 @@
@@ -1,47 +0,0 @@
|
||||
----- |
||||
Debug the application |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2014-05-14 |
||||
----- |
||||
|
||||
By default, the <<<run>>> goal runs your application in a forked process. If you need to |
||||
debug it, you should add the necessary JVM arguments to enable remote debugging. The |
||||
following configuration suspend the process until a debugger has joined on port 5005: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<configuration> |
||||
<jvmArguments> |
||||
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 |
||||
</jvmArguments> |
||||
</configuration> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
These arguments can be specified on the command line as well, make sure to wrap that |
||||
properly, that is: |
||||
|
||||
--- |
||||
mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005" |
||||
--- |
||||
|
||||
|
||||
|
||||
@ -1,51 +0,0 @@
@@ -1,51 +0,0 @@
|
||||
----- |
||||
Using environment variables |
||||
----- |
||||
Dmytro Nosan |
||||
----- |
||||
2018-04-08 |
||||
----- |
||||
|
||||
Environment variables can be specified using the <<<environmentVariables>>> attribute. |
||||
The following sets the 'ENV1', 'ENV2', 'ENV3', 'ENV4' env variables: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<configuration> |
||||
<environmentVariables> |
||||
<ENV1>5000</ENV1> |
||||
<ENV2>Some Text</ENV2> |
||||
<ENV3/> |
||||
<ENV4></ENV4> |
||||
</environmentVariables> |
||||
</configuration> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
If the value is empty or not defined (i.e. <<<<MY_ENV/>>>>), the env variable is set |
||||
with an empty String as the value. Maven trims values specified in the pom so it is |
||||
not possible to specify an env variable which needs to start or end with a space. |
||||
|
||||
Any String typed Maven variable can be passed as system properties. Any attempt to pass |
||||
any other Maven variable type (e.g. a <<<List>>> or a <<<URL>>> variable) will cause the |
||||
variable expression to be passed literally (unevaluated). |
||||
|
||||
Environment variables defined this way take precedence over existing values. |
||||
|
||||
|
||||
@ -1,47 +0,0 @@
@@ -1,47 +0,0 @@
|
||||
----- |
||||
Specify active profiles |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2014-07-07 |
||||
----- |
||||
|
||||
The active profiles to use for a particular application can be specified using the <<<profiles>>> |
||||
argument. The following configuration enables the foo and bar profiles: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<configuration> |
||||
<profiles> |
||||
<profile>foo</profile> |
||||
<profile>bar</profile> |
||||
</profiles> |
||||
</configuration> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
The profiles to enable can be specified on the command line as well, make sure to separate them with |
||||
a comma, that is: |
||||
|
||||
--- |
||||
mvn spring-boot:run -Dspring-boot.run.profiles=foo,bar |
||||
--- |
||||
|
||||
|
||||
|
||||
@ -1,61 +0,0 @@
@@ -1,61 +0,0 @@
|
||||
----- |
||||
Using System Properties |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2018-04-24 |
||||
----- |
||||
|
||||
System properties can be specified using the <<<systemPropertyVariables>>> attribute. |
||||
The following sets <<<property1>>> to <<<test>>> and <<<property2>>> to 42: |
||||
|
||||
--- |
||||
<project> |
||||
... |
||||
<build> |
||||
<properties> |
||||
<my.value>42</my.value> |
||||
</properties> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<configuration> |
||||
<systemPropertyVariables> |
||||
<property1>test</property1> |
||||
<property2>${my.value}</property2> |
||||
</systemPropertyVariables> |
||||
</configuration> |
||||
... |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
... |
||||
</project> |
||||
--- |
||||
|
||||
If the value is empty or not defined (i.e. <<<<my-property/>>>>), the system property |
||||
is set with an empty String as the value. Maven trims values specified in the pom so it |
||||
is not possible to specify a System property which needs to start or end with a space via |
||||
this mechanism: consider using <<<jvmArguments>>> instead. |
||||
|
||||
Any String typed Maven variable can be passed as system properties. Any attempt to pass |
||||
any other Maven variable type (e.g. a <<<List>>> or a <<<URL>>> variable) will cause the |
||||
variable expression to be passed literally (unevaluated). |
||||
|
||||
The <<<jvmArguments>>> parameter takes precedence over system properties defined with |
||||
the mechanism above. In the following example, the value for <<<property1>>> is |
||||
<<<overridden>>>: |
||||
|
||||
|
||||
--- |
||||
mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dproperty1=overridden" |
||||
--- |
||||
|
||||
|
||||
|
||||
@ -1,74 +0,0 @@
@@ -1,74 +0,0 @@
|
||||
----- |
||||
Spring Boot |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2014-05-02 |
||||
----- |
||||
|
||||
Spring Boot Maven Plugin |
||||
|
||||
The Spring Boot Maven Plugin provides Spring Boot support in Maven, allowing you to package executable |
||||
jar or war archives and run an application “in-place”. |
||||
|
||||
* Goals Overview |
||||
|
||||
The Spring Boot Plugin has the following goals. |
||||
|
||||
* {{{./run-mojo.html}spring-boot:run}} runs your Spring Boot application. |
||||
|
||||
* {{{./repackage-mojo.html}spring-boot:repackage}} repackages your jar/war to be executable. |
||||
|
||||
* {{{./start-mojo.html}spring-boot:start}} and {{{./stop-mojo.html}spring-boot:stop}} to manage |
||||
the lifecycle of your Spring Boot application (i.e. for integration tests). |
||||
|
||||
* {{{./build-info-mojo.html}spring-boot:build-info}} generates build information that can be used |
||||
by the Actuator. |
||||
|
||||
|
||||
|
||||
* Usage |
||||
|
||||
General instructions on how to use the Spring Boot Plugin can be found on the {{{./usage.html}usage page}}. Some |
||||
more specific use cases are described in the examples given below. |
||||
|
||||
In case you still have questions regarding the plugin's usage, please have a look at the existing |
||||
{{{https://stackoverflow.com/questions/tagged/spring-boot}stack overflow issue}}. If you still don't get an |
||||
answer, feel free to create a new thread with the <<<#spring-boot>>> tag. |
||||
|
||||
If you feel like the plugin is missing a feature or has a defect, you can fill a feature request or bug report |
||||
in our {{{./issue-tracking.html}issue tracker}}. |
||||
|
||||
* Examples |
||||
|
||||
To provide you with better understanding of some usages of Spring Boot, you can take a look into |
||||
the following examples: |
||||
|
||||
* {{{./examples/repackage-classifier.html}Custom repackage classifier}} |
||||
|
||||
* {{{./examples/repackage-name.html}Custom repackage name}} |
||||
|
||||
* {{{./examples/repackage-disable-attach.html}Local repackaged artifact}} |
||||
|
||||
* {{{./examples/exclude-dependency.html}Exclude a dependency}} |
||||
|
||||
* {{{./examples/run-debug.html}Debug the application}} |
||||
|
||||
* {{{./examples/run-system-properties.html}Using system properties}} |
||||
|
||||
* {{{./examples/run-env-variables.html}Using environment variables}} |
||||
|
||||
* {{{./examples/it-random-port.html}Random port for integration tests}} |
||||
|
||||
* {{{./examples/it-skip.html}Skip integration tests}} |
||||
|
||||
* {{{./examples/run-profiles.html}Specify active profiles}} |
||||
|
||||
* {{{./examples/build-info.html}Generate build information}} |
||||
|
||||
* {{{./examples/custom-layout.html}Custom layout}} |
||||
|
||||
[] |
||||
|
||||
|
||||
|
||||
@ -1,314 +0,0 @@
@@ -1,314 +0,0 @@
|
||||
|
||||
----- |
||||
Usage |
||||
----- |
||||
Stephane Nicoll |
||||
----- |
||||
2014-05-06 |
||||
----- |
||||
|
||||
Usage |
||||
|
||||
The plugin provides several goals to work with a Spring Boot application: |
||||
|
||||
* <<<repackage>>>: create a jar or war file that is auto-executable. It can replace the regular artifact or can be |
||||
attached to the build lifecycle with a separate <<classifier>>. |
||||
|
||||
* <<<run>>>: run your Spring Boot application with several options to pass parameters to it. |
||||
|
||||
* <<<start>>> and <<<stop>>>: integrate your Spring Boot application to the <<<integration-test>>> phase so that |
||||
the application starts before it. |
||||
|
||||
* <<<build-info>>>: generate a build information that can be used by the Actuator. |
||||
|
||||
[] |
||||
|
||||
Each goal is further described below. |
||||
|
||||
* Repackaging an application |
||||
|
||||
In order to repackage your application, you simply need to add a reference to the |
||||
plugin in your <<<pom.xml>>>: |
||||
|
||||
--- |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<goals> |
||||
<goal>repackage</goal> |
||||
</goals> |
||||
</execution> |
||||
</executions> |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
--- |
||||
|
||||
The example above repackages a jar or war that is built during the package phase of the Maven lifecycle, |
||||
including any <<<provided>>> dependencies that are defined in the project. If some of these dependencies |
||||
need to be excluded, you can use one of the exclude options, |
||||
see {{{./examples/exclude-dependency.html}Exclude a dependency}} for more details. |
||||
Please note that the <<<outputFileNameMapping>>> feature of the <<<maven-war-plugin>>> |
||||
is currently not supported. |
||||
|
||||
Devtools is automatically excluded by default (you can control that using the |
||||
<<<excludeDevtools>>> property). In order to make that work with <<<war>>> packaging, |
||||
the <<<spring-boot-devtools>>> dependency must be set as <<<optional>>> or with the |
||||
<<<provided>>> scope. |
||||
|
||||
The original (i.e. non executable) artifact is renamed to <<<.original>>> by default but it is also |
||||
possible to keep the original artifact using a custom classifier. |
||||
|
||||
The plugin rewrites your manifest, and in particular it manages the <<Main-Class>> and <<Start-Class>> |
||||
entries, so if the defaults don't work you have to configure those there (not in the jar plugin). The |
||||
<<Main-Class>> in the manifest is actually controlled by the <<layout>> property of the boot plugin, e.g. |
||||
|
||||
--- |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<configuration> |
||||
<mainClass>${start-class}</mainClass> |
||||
<layout>ZIP</layout> |
||||
</configuration> |
||||
<executions> |
||||
<execution> |
||||
<goals> |
||||
<goal>repackage</goal> |
||||
</goals> |
||||
</execution> |
||||
</executions> |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
--- |
||||
|
||||
The <<<layout>>> property defaults to a guess based on the archive type (<<<jar>>> or <<<war>>>). The |
||||
following layouts are available: |
||||
|
||||
* <<<JAR>>>: regular executable JAR layout. |
||||
|
||||
* <<<WAR>>>: executable WAR layout. <<<provided>>> dependencies are placed in <<<WEB-INF/lib-provided>>> |
||||
to avoid any clash when the <<<war>>> is deployed in a servlet container. |
||||
|
||||
* <<<ZIP>>> (alias to <<<DIR>>>): similar to the <<<JAR>>> layout using <<<PropertiesLauncher>>>. |
||||
|
||||
* <<<NONE>>>: Bundle all dependencies and project resources. Does not bundle a bootstrap loader. |
||||
|
||||
[] |
||||
|
||||
For more detailed examples of how to configure this goal see: |
||||
|
||||
* {{{./examples/repackage-classifier.html}Custom repackage classifier}} |
||||
|
||||
* {{{./examples/exclude-dependency.html}Exclude a dependency}} |
||||
|
||||
[] |
||||
|
||||
* Running the application |
||||
|
||||
The plugin includes a run goal which can be used to launch your application from the command |
||||
line: |
||||
|
||||
--- |
||||
mvn spring-boot:run |
||||
--- |
||||
|
||||
By default the application is executed in a forked process and setting properties on the |
||||
command-line will not affect the application. If you need to specify some JVM arguments |
||||
(i.e. for debugging purposes), you can use the <<<jvmArguments>>> parameter, see |
||||
{{{./examples/run-debug.html}Debug the application}} for more details. There is also |
||||
explicit support for {{{./examples/run-system-properties.html}system properties}} and |
||||
{{{./examples/run-env-variables.html}environment variables}}. |
||||
|
||||
As enabling a profile is quite common, there is dedicated <<<profiles>>> property that |
||||
offers a shortcut for |
||||
<<<-Dspring-boot.run.jvmArguments="-Dspring.profiles.active=dev">>>, |
||||
see {{{./examples/run-profiles.html}Specify active profiles}}. |
||||
|
||||
Although this is not recommended, it is possible to execute the application directly |
||||
from the Maven JVM by disabling the <<<fork>>> property. Doing so means that the |
||||
<<<jvmArguments>>>, <<<systemPropertyVariables>>>, <<<environmentVariables>>> and |
||||
<<<agents>>> options are ignored. |
||||
|
||||
Spring Boot 1.3 has introduced <<<devtools>>>, a module to improve the development-time |
||||
experience when working on Spring Boot applications. To enable it, just add the following |
||||
dependency to your project: |
||||
|
||||
--- |
||||
<dependencies> |
||||
<dependency> |
||||
<groupId>org.springframework.boot</groupId> |
||||
<artifactId>spring-boot-devtools</artifactId> |
||||
<version>${project.version}</version> |
||||
<optional>true</optional> |
||||
</dependency> |
||||
</dependencies> |
||||
--- |
||||
|
||||
When <<<devtools>>> is running, it detects change when you recompile your application and |
||||
automatically refreshes it. This works for not only resources but code as well. It also |
||||
provides a LiveReload server so that it can automatically trigger a browser refresh whenever |
||||
things change. |
||||
|
||||
Devtools can also be configured to only refresh the browser whenever a static resource has |
||||
changed (and ignore any change in the code). Just include the following property in your |
||||
project: |
||||
|
||||
--- |
||||
spring.devtools.remote.restart.enabled=false |
||||
--- |
||||
|
||||
Prior to <<<devtools>>>, the plugin supported hot refreshing of resources by default which has |
||||
now be disabled in favour of the solution described above. You can restore it at any time by |
||||
configuring your project: |
||||
|
||||
--- |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<configuration> |
||||
<addResources>true</addResources> |
||||
</configuration> |
||||
</plugin> |
||||
... |
||||
</plugins> |
||||
... |
||||
</build> |
||||
--- |
||||
|
||||
When <<<addResources>>> is enabled, any <<src/main/resources>> folder will be added to |
||||
the application classpath when you run the application and any duplicate found in |
||||
<<target/classes>> will be removed. This allows hot refreshing of resources which can be very |
||||
useful when developing web applications. For example, you can work on HTML, CSS or JavaScript |
||||
files and see your changes immediately without recompiling your application. It is also a helpful |
||||
way of allowing your front end developers to work without needing to download and install a Java |
||||
IDE. |
||||
|
||||
Note that a side effect of using this feature is that filtering of resources at build time will |
||||
not work. |
||||
|
||||
In order to be consistent with the <<<repackage>>> goal, the <<<run>>> goal builds the classpath |
||||
in such a way that any dependency that is excluded in the plugin's configuration gets excluded |
||||
from the classpath as well. See {{{./examples/exclude-dependency.html}Exclude a dependency}} for |
||||
more details. |
||||
|
||||
Sometimes it is useful to include test dependencies when running the application. For example, |
||||
if you want to run your application in a test mode that uses stub classes. If you wish to do this, |
||||
you can set the <<<useTestClasspath>>> parameter to true. Note that this is only applied when you |
||||
run an application: the <<<repackage>>> goal will not add test dependencies to the resulting JAR/WAR. |
||||
|
||||
* Working with integration tests |
||||
|
||||
While you may start your Spring Boot application very easily from your test (or test suite) itself, |
||||
it may be desirable to handle that in the build itself. To make sure that the lifecycle of your Spring |
||||
Boot application is properly managed <around> your integration tests, you can use the <<<start>>> and |
||||
<<<stop>>> goals as described below: |
||||
|
||||
--- |
||||
<build> |
||||
... |
||||
<plugins> |
||||
... |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</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> |
||||
--- |
||||
|
||||
Such setup can now use the {{{https://maven.apache.org/surefire/maven-failsafe-plugin/}failsafe-plugin}} to |
||||
run your integration tests as you would expect. |
||||
|
||||
You could also configure a more advanced setup to skip the integration tests when a specific property has |
||||
been set: |
||||
|
||||
--- |
||||
<properties> |
||||
<it.skip>false</it.skip> |
||||
</properties> |
||||
<build> |
||||
<plugins> |
||||
<plugin> |
||||
<groupId>org.apache.maven.plugins</groupId> |
||||
<artifactId>maven-failsafe-plugin</artifactId> |
||||
<configuration> |
||||
<skip>${it.skip}</skip> |
||||
</configuration> |
||||
</plugin> |
||||
<plugin> |
||||
<groupId>${project.groupId}</groupId> |
||||
<artifactId>${project.artifactId}</artifactId> |
||||
<version>${project.version}</version> |
||||
<executions> |
||||
<execution> |
||||
<id>pre-integration-test</id> |
||||
<goals> |
||||
<goal>start</goal> |
||||
</goals> |
||||
<configuration> |
||||
<skip>${it.skip}</skip> |
||||
</configuration> |
||||
</execution> |
||||
<execution> |
||||
<id>post-integration-test</id> |
||||
<goals> |
||||
<goal>stop</goal> |
||||
</goals> |
||||
<configuration> |
||||
<skip>${it.skip}</skip> |
||||
</configuration> |
||||
</execution> |
||||
</executions> |
||||
</plugin> |
||||
</plugins> |
||||
</build> |
||||
--- |
||||
|
||||
If you run <<<mvn verify -Dit.skip=true>>> your integration tests will be skipped altogether. |
||||
|
||||
|
||||
For more detailed examples of how to configure this goal see: |
||||
|
||||
* {{{./examples/it-random-port.html}Random port for integration tests}} |
||||
|
||||
[] |
||||
@ -1,30 +0,0 @@
@@ -1,30 +0,0 @@
|
||||
<project xmlns="http://maven.apache.org/DECORATION/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" |
||||
xsi:schemaLocation="http://maven.apache.org/DECORATION/1.0.0 https://maven.apache.org/xsd/decoration-1.0.0.xsd"> |
||||
<body> |
||||
<menu name="Overview"> |
||||
<item name="Introduction" href="index.html"/> |
||||
<item name="Goals" href="plugin-info.html"/> |
||||
<item name="Usage" href="usage.html"/> |
||||
</menu> |
||||
<menu name="Examples"> |
||||
<item name="Custom repackage classifier" href="examples/repackage-classifier.html"/> |
||||
<item name="Custom repackage name" href="examples/repackage-name.html"/> |
||||
<item name="Local repackaged artifact" href="examples/repackage-disable-attach.html"/> |
||||
<item name="Exclude a dependency" href="examples/exclude-dependency.html"/> |
||||
<item name="Debug the application" href="examples/run-debug.html"/> |
||||
<item name="Using system properties" href="examples/run-system-properties.html"/> |
||||
<item name="Using environment variable" href="examples/run-env-variables.html"/> |
||||
<item name="Random port for integration tests" href="examples/it-random-port.html"/> |
||||
<item name="Skip integration tests" href="examples/it-skip.html"/> |
||||
<item name="Specify active profiles" href="examples/run-profiles.html"/> |
||||
<item name="Generate build information" href="examples/build-info.html"/> |
||||
<item name="Custom layout" href="examples/custom-layout.html"/> |
||||
</menu> |
||||
<menu ref="reports"/> |
||||
</body> |
||||
<skin> |
||||
<groupId>org.apache.maven.skins</groupId> |
||||
<artifactId>maven-fluido-skin</artifactId> |
||||
<version>1.6</version> |
||||
</skin> |
||||
</project> |
||||
Loading…
Reference in new issue