87. Build

Spring Boot includes build plugins for Maven and Gradle. This section answers common
questions about these plugins.

87.1 Generate Build Information

Both the Maven plugin and the Gradle plugin allow generating build information containing
the coordinates, name, and version of the project. The plugins can also be configured
to add additional properties through configuration. When such a file is present,
Spring Boot auto-configures a BuildProperties bean.

To generate build information with Maven, add an execution for the build-info goal, as
shown in the following example:

Gradle users can achieve the same result by using the
gradle-git-properties
plugin, as shown in the following example:

plugins {
id "com.gorylenko.gradle-git-properties" version "1.5.1"
}

Tip

The commit time in git.properties is expected to match the following format:
yyyy-MM-dd’T’HH:mm:ssZ. This is the default format for both plugins listed above. Using
this format lets the time be parsed into a Date and its format, when serialized to JSON,
to be controlled by Jackson’s date serialization configuration settings.

87.3 Customize Dependency Versions

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 property:

<properties><slf4j.version>1.7.5<slf4j.version></properties>

Note

Doing so only works if your Maven project inherits (directly or indirectly) from
spring-boot-dependencies. If you have added spring-boot-dependencies in your
own dependencyManagement section with <scope>import</scope>, you have to redefine
the artifact yourself instead of overriding the property.

Warning

Each Spring Boot release is designed and tested against this specific set of
third-party dependencies. Overriding versions may cause compatibility issues.

To override dependency versions in Gradle, see this section
of the Gradle plugin’s documentation.

87.4 Create an Executable JAR with Maven

The spring-boot-maven-plugin can be used to create an executable “fat” JAR. If you
use the spring-boot-starter-parent POM, you can declare the plugin and your jars are
repackaged as follows:

87.5 Use a Spring Boot Application as a Dependency

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 a dependency.

To configure a classifier of exec in Maven, you can use the following configuration:

87.6 Extract Specific Libraries When an Executable Jar Runs

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 unpacking by using the Maven
Plugin, you would add the following configuration:

87.7 Create a Non-executable JAR with Exclusions

Often, if you have an executable and a non-executable jar as two separate build products,
the executable version has additional configuration files that are not needed in a library
jar. For example, the application.yml configuration file might by excluded from the
non-executable JAR.

In Maven, the executable jar must be the main artifact and you can add a classified jar
for the library, as follows:

87.8 Remote Debug a Spring Boot Application Started with Maven

87.9 Build an Executable Archive from Ant without Using spring-boot-antlib

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:

If you are building a jar, package the application’s classes and resources in a nested
BOOT-INF/classes directory. If you are building a war, package the application’s
classes in a nested WEB-INF/classes directory as usual.

Add the runtime dependencies in a nested BOOT-INF/lib directory for a jar or
WEB-INF/lib for a war. Remember not to compress the entries in the archive.

Add the provided (embedded container) dependencies in a nested BOOT-INF/lib
directory for a jar or WEB-INF/lib-provided for a war. Remember not to compress the
entries in the archive.

Add the spring-boot-loader classes at the root of the archive (so that the Main-Class
is available).

Use the appropriate launcher (such as JarLauncher for a jar file) as a Main-Class
attribute in the manifest and specify the other properties it needs as manifest entries — principally, by setting a Start-Class property.

The following example shows how to build an executable archive with Ant: