Polish "Replace the Maven Plugin's site with Asciidoctor documentation"
See gh-19080
This commit is contained in:
Stephane Nicoll
parent
204a552c35
commit
a76a864270
|
|
@ -51,7 +51,7 @@ import org.springframework.boot.loader.tools.Repackager;
|
|||
import org.springframework.boot.loader.tools.Repackager.MainClassTimeoutWarningListener;
|
||||
|
||||
/**
|
||||
* Repackages existing JAR and WAR archives so that they can be executed from the command
|
||||
* Repackage existing JAR and WAR archives so that they can be executed from the command
|
||||
* line using {@literal java -jar}. With <code>layout=NONE</code> can also be used simply
|
||||
* to package a JAR with nested dependencies (and no main class, so not executable).
|
||||
*
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ import org.springframework.boot.loader.tools.JavaExecutable;
|
|||
import org.springframework.boot.loader.tools.RunProcess;
|
||||
|
||||
/**
|
||||
* Run an executable archive application.
|
||||
* Run an application in place.
|
||||
*
|
||||
* @author Phillip Webb
|
||||
* @author Dmytro Nosan
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ import org.springframework.boot.loader.tools.RunProcess;
|
|||
|
||||
/**
|
||||
* Start a spring application. Contrary to the {@code run} goal, this does not block and
|
||||
* allows other goal to operate on the application. This goal is typically used in
|
||||
* allows other goals to operate on the application. This goal is typically used in
|
||||
* integration test scenario where the application is started before a test suite and
|
||||
* stopped after.
|
||||
*
|
||||
|
|
|
|||
|
|
@ -32,8 +32,8 @@ import org.apache.maven.plugins.annotations.Parameter;
|
|||
import org.apache.maven.project.MavenProject;
|
||||
|
||||
/**
|
||||
* Stop a spring application that has been started by the "start" goal. Typically invoked
|
||||
* once a test suite has completed.
|
||||
* Stop an application that has been started by the "start" goal. Typically invoked once a
|
||||
* test suite has completed.
|
||||
*
|
||||
* @author Stephane Nicoll
|
||||
* @since 1.3.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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
-----
|
||||
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 @@
|
|||
|
||||
-----
|
||||
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 @@
|
|||
<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