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. |
To override dependency versions in Gradle, you can specify a version as shown below:
ext['slf4j.version'] = '1.7.5'
For additional information, please refer to the Gradle Dependency Management Plugin documentation.
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>1.3.3.RELEASE</version> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
See the plugin documentation for full usage details.
If you want to use your project as a library jar for other projects to depend on, and in addition have an executable (e.g. demo) version of it, you will want to configure the build in a slightly different way.
For Maven the normal JAR plugin and the Spring Boot plugin both have a ‘classifier’ configuration that you can add to create an additional JAR. Example (using the Spring Boot Starter Parent to manage the plugin versions and other configuration defaults):
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <classifier>exec</classifier> </configuration> </plugin> </plugins> </build>
Two jars are produced, the default one, and an executable one using the Boot plugin with classifier ‘exec’.
For Gradle users the steps are similar. Example:
bootRepackage {
classifier = 'exec'
}
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>
And to do that same with Gradle:
springBoot {
requiresUnpack = ['org.jruby:jruby-complete']
}
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.
Here’s how to do that in Maven:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <classifier>exec</classifier> </configuration> </plugin> <plugin> <artifactId>maven-jar-plugin</artifactId> <executions> <execution> <id>exec</id> <phase>package</phase> <goals> <goal>jar</goal> </goals> <configuration> <classifier>exec</classifier> </configuration> </execution> <execution> <phase>package</phase> <goals> <goal>jar</goal> </goals> <configuration> <!-- Need this to ensure application.yml is excluded --> <forceCreation>true</forceCreation> <excludes> <exclude>application.yml</exclude> </excludes> </configuration> </execution> </executions> </plugin> </plugins> </build>
In Gradle you can create a new JAR archive with standard task DSL features, and then have
the bootRepackage
task depend on that one using its withJarTask
property:
jar { baseName = 'spring-boot-sample-profile' version = '0.0.0' excludes = ['**/application.yml'] } task('execJar', type:Jar, dependsOn: 'jar') { baseName = 'spring-boot-sample-profile' version = '0.0.0' classifier = 'exec' from sourceSets.main.output } bootRepackage { withJarTask = tasks['execJar'] }
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 attach a remote debugger to a Spring Boot application started with Gradle you can use
the applicationDefaultJvmArgs
in build.gradle
or --debug-jvm
command line option.
build.gradle
:
applicationDefaultJvmArgs = [
"-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"
]
Command line:
$ gradle run --debug-jvm
Check Gradle Application Plugin for more details.
To build with Ant you need to grab dependencies, compile and then create a jar or war
archive as normal. To make it executable you can either use the spring-boot-antlib
module, or you can follow these instructions:
Main-Class
, e.g. JarLauncher
for a jar file, and
specify the other properties it needs as manifest entries, principally a Start-Class
.provided
(embedded container) dependencies in a nested lib-provided
directory.
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).Example:
<target name="build" depends="compile"> <copy todir="target/classes/lib"> <fileset dir="lib/runtime" /> </copy> <jar destfile="target/spring-boot-sample-actuator-${spring-boot.version}.jar" compress="false"> <fileset dir="target/classes" /> <fileset dir="src/main/resources" /> <zipfileset src="lib/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 Actuator Sample has a build.xml
that should work if you run it with
$ ant -lib <folder containing ivy-2.2.jar>
after which you can run the application with
$ java -jar target/*.jar
If you want to use Spring Boot with Java 6 there are a small number of configuration changes that you will have to make. The exact changes depend on your application’s functionality.
If you are using one of Boot’s embedded Servlet containers you will have to use a Java 6-compatible container. Both Tomcat 7 and Jetty 8 are Java 6 compatible. See Section 70.15, “Use Tomcat 7” and Section 70.16, “Use Jetty 8” for details.
While the Java Transaction API itself doesn’t require Java 7 the official API jar
contains classes that have been built to require Java 7. If you are using JTA then
you will need to replace the official JTA 1.2 API jar with one that has been built
to work on Java 6. To do so, exclude any transitive dependencies on
javax.transaction:javax.transaction-api
and replace them with a dependency on
org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:1.0.0.Final