Relocate projects to spring-boot-project
Move projects to better reflect the way that Spring Boot is released. The following projects are under `spring-boot-project`: - `spring-boot` - `spring-boot-autoconfigure` - `spring-boot-tools` - `spring-boot-starters` - `spring-boot-actuator` - `spring-boot-actuator-autoconfigure` - `spring-boot-test` - `spring-boot-test-autoconfigure` - `spring-boot-devtools` - `spring-boot-cli` - `spring-boot-docs` See gh-9316
This commit is contained in:
Phillip Webb
@@ -0,0 +1,56 @@
|
||||
-----
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
-----
|
||||
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>
|
||||
<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.
|
||||
@@ -0,0 +1,113 @@
|
||||
-----
|
||||
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 three 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 matching a given <<<artifactId>>>
|
||||
|
||||
* 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 artifacts having the <<<my-lib>>> or <<<another-lib>>>
|
||||
artifact identifiers
|
||||
|
||||
---
|
||||
<project>
|
||||
...
|
||||
<build>
|
||||
...
|
||||
<plugins>
|
||||
...
|
||||
<plugin>
|
||||
<groupId>${project.groupId}</groupId>
|
||||
<artifactId>${project.artifactId}</artifactId>
|
||||
<version>${project.version}</version>
|
||||
<configuration>
|
||||
<excludeArtifactIds>my-lib,another-lib</excludeArtifactIds>
|
||||
</configuration>
|
||||
...
|
||||
</plugin>
|
||||
...
|
||||
</plugins>
|
||||
...
|
||||
</build>
|
||||
...
|
||||
</project>
|
||||
---
|
||||
|
||||
Finally 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>
|
||||
---
|
||||
|
||||
@@ -0,0 +1,82 @@
|
||||
-----
|
||||
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
|
||||
{{{http://mojo.codehaus.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.
|
||||
@@ -0,0 +1,63 @@
|
||||
-----
|
||||
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>>>.
|
||||
@@ -0,0 +1,55 @@
|
||||
-----
|
||||
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 behaviour 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>
|
||||
<goals>
|
||||
<goal>repackage</goal>
|
||||
</goals>
|
||||
<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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
-----
|
||||
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>
|
||||
<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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
-----
|
||||
Debug the application
|
||||
-----
|
||||
Stephane Nicoll
|
||||
-----
|
||||
2014-05-14
|
||||
-----
|
||||
|
||||
By default, the <<<run>>> goal runs in the same process unless jvm arguments or an agent have been specified. You
|
||||
can enable or disable forking explicitly using the <<<fork>>> attribute.
|
||||
|
||||
If you need to fork the process and debug it you can 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>
|
||||
---
|
||||
|
||||
Note that since you specified some JVM arguments, the process is forked automatically. 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"
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
-----
|
||||
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
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,68 @@
|
||||
-----
|
||||
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
|
||||
{{{http://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-disable-attach.html}Local repackaged artifact}}
|
||||
|
||||
* {{{./examples/exclude-dependency.html}Exclude a dependency}}
|
||||
|
||||
* {{{./examples/run-debug.html}Debug the application}}
|
||||
|
||||
* {{{./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}}
|
||||
|
||||
[]
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,309 @@
|
||||
|
||||
-----
|
||||
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>>>.
|
||||
|
||||
* <<<MODULE>>>: Bundle dependencies (excluding those with <<<provided>>> scope) and project resources.
|
||||
Does not bundle a bootstrap loader.
|
||||
|
||||
* <<<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 directly from the Maven JVM. If you need to run
|
||||
in a forked process you can use the 'fork' option. Forking will also occur if the
|
||||
'jvmArguments' or 'agent' options are specified, or if devtools is present.
|
||||
|
||||
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. As a convenience, the profiles to enable are handled by a specific
|
||||
property (<<<profiles>>>), see {{{./examples/run-profiles.html}Specify active profiles}}.
|
||||
|
||||
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 you 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 {{{http://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}}
|
||||
|
||||
[]
|
||||
@@ -0,0 +1,27 @@
|
||||
<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 http://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="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="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.3.1</version>
|
||||
</skin>
|
||||
</project>
|
||||
Reference in New Issue
Block a user