Both the Maven and Gradle plugin allow to generate build information containing
the coordinates, name and version of the project. The plugin can also be configured
to add additional properties through configuration. When such file is present,
Spring Boot auto-configures a BuildProperties
bean.
To generate build information with Maven, add an execution for the build-info
goal:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>2.0.0.M4</version> <executions> <execution> <goals> <goal>build-info</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
![]() | Tip |
---|---|
Check the Spring Boot Maven Plugin documentation for more details. |
And to do the same with Gradle:
springBoot { buildInfo() }
Additional properties can be added using the DSL:
springBoot { buildInfo { additionalProperties = [ 'foo': 'bar' ] } }
Both Maven and Gradle allow to generate a git.properties
file containing information
about the state of your git
source code repository when the project was built.
For Maven users the spring-boot-starter-parent
POM includes a pre-configured plugin to
generate a git.properties
file. Simply add the following declaration to your POM:
<build> <plugins> <plugin> <groupId>pl.project13.maven</groupId> <artifactId>git-commit-id-plugin</artifactId> </plugin> </plugins> </build>
Gradle users can achieve the same result using the
gradle-git-properties
plugin
plugins { id "com.gorylenko.gradle-git-properties" version "1.4.17" }
If you use a Maven build that inherits directly or indirectly from spring-boot-dependencies
(for instance spring-boot-starter-parent
) but you want to override a specific
third-party dependency you can add appropriate <properties>
elements. Browse
the spring-boot-dependencies
POM for a complete list of properties. For example, to pick a different slf4j
version
you would add the following:
<properties> <slf4j.version>1.7.5<slf4j.version> </properties>
![]() | Note |
---|---|
This only works if your Maven project inherits (directly or indirectly) from
|
![]() | Warning |
---|---|
Each Spring Boot release is designed and tested against a specific set of third-party dependencies. Overriding versions may cause compatibility issues. |
The spring-boot-maven-plugin
can be used to create an executable ‘fat’ JAR. If you
are using the spring-boot-starter-parent
POM you can simply declare the plugin and
your jars will be repackaged:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>
If you are not using the parent POM you can still use the plugin, however, you must
additionally add an <executions>
section:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>2.0.0.M4</version> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
See the plugin documentation for full usage details.
Like a war file, a Spring Boot application is not intended to be used as a dependency. If your application contains classes that you want to share with other projects, the recommended approach is to move that code into a separate module. The separate module can then be depended upon by your application and other projects.
If you cannot rearrange your code as recommended above, Spring Boot’s Maven and Gradle
plugins must be configured to produce a separate artifact that is suitable for use as a
dependency. The executable archive cannot be used as a dependency as the
executable jar
format packages application classes in BOOT-INF/classes
. This means
that they cannot be found when the executable jar is used as a dependency.
To produce the two artifacts, one that can be used as a dependency and one that is executable, a classifier must be specified. This classifier is applied to the name of the executable archive, leaving the default archive for use as dependency.
To configure a classifier of exec
in Maven, the following configuration can be used:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <classifier>exec</classifier> </configuration> </plugin> </plugins> </build>
Most nested libraries in an executable jar do not need to be unpacked in order to run,
however, certain libraries can have problems. For example, JRuby includes its own nested
jar support which assumes that the jruby-complete.jar
is always directly available as a
file in its own right.
To deal with any problematic libraries, you can flag that specific nested jars should be automatically unpacked to the ‘temp folder’ when the executable jar first runs.
For example, to indicate that JRuby should be flagged for unpack using the Maven Plugin you would add the following configuration:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <requiresUnpack> <dependency> <groupId>org.jruby</groupId> <artifactId>jruby-complete</artifactId> </dependency> </requiresUnpack> </configuration> </plugin> </plugins> </build>
Often if you have an executable and a non-executable jar as build products, the executable
version will have additional configuration files that are not needed in a library jar.
E.g. the application.yml
configuration file might excluded from the non-executable JAR.
The maven-jar-plugin
used to expose a forceCreation
attribute that allows you to
create the jar again once the repackage
goal has ran. Arguably, this was a bit fragile
anyway since it was relying on the order of plugin executions. In Maven, the executable
jar must be the main artifact and you can add a classified jar for the library:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <plugin> <artifactId>maven-jar-plugin</artifactId> <executions> <execution> <id>lib</id> <phase>package</phase> <goals> <goal>jar</goal> </goals> <configuration> <classifier>lib</classifier> <excludes> <exclude>application.yml</exclude> </excludes> </configuration> </execution> </executions> </plugin> </plugins> </build>
To attach a remote debugger to a Spring Boot application started with Maven you can use
the jvmArguments
property of the maven plugin.
Check this example for more details.
To build with Ant you need to grab dependencies, compile and then create a jar or war
archive. To make it executable you can either use the spring-boot-antlib
module, or you can follow these instructions:
BOOT-INF/classes
directory. If you are building a war, package the application’s
classes in a nested WEB-INF/classes
directory as usual.BOOT-INF/lib
directory for a jar or
WEB-INF/lib
for a war. Remember not to compress the entries in the archive.provided
(embedded container) dependencies in a nested BOOT-INF/lib
directory for jar or WEB-INF/lib-provided
for a war. Remember not to compress the
entries in the archive.spring-boot-loader
classes at the root of the archive (so the Main-Class
is available).JarLauncher
for a jar file, as a Main-Class
attribute in the manifest and specify the other properties it needs as manifest entries,
principally a Start-Class
.Example:
<target name="build" depends="compile"> <jar destfile="target/${ant.project.name}-${spring-boot.version}.jar" compress="false"> <mappedresources> <fileset dir="target/classes" /> <globmapper from="*" to="BOOT-INF/classes/*"/> </mappedresources> <mappedresources> <fileset dir="src/main/resources" erroronmissingdir="false"/> <globmapper from="*" to="BOOT-INF/classes/*"/> </mappedresources> <mappedresources> <fileset dir="${lib.dir}/runtime" /> <globmapper from="*" to="BOOT-INF/lib/*"/> </mappedresources> <zipfileset src="${lib.dir}/loader/spring-boot-loader-jar-${spring-boot.version}.jar" /> <manifest> <attribute name="Main-Class" value="org.springframework.boot.loader.JarLauncher" /> <attribute name="Start-Class" value="${start-class}" /> </manifest> </jar> </target>
The Ant Sample has a
build.xml
with a manual
task that should work if you run it with
$ ant -lib <folder containing ivy-2.2.jar> clean manual
after which you can run the application with
$ java -jar target/*.jar