![]() |
Spring Boot includes build plugins for Maven and Gradle. This section answers common questions about these plugins. 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 To generate build information with Maven, add an execution for the <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>2.0.5.RELEASE</version> <executions> <execution> <goals> <goal>build-info</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
The following example does the same with Gradle: springBoot { buildInfo() }
Both Maven and Gradle allow generating a For Maven users, the <build> <plugins> <plugin> <groupId>pl.project13.maven</groupId> <artifactId>git-commit-id-plugin</artifactId> </plugin> </plugins> </build> Gradle users can achieve the same result by using the
plugins { id "com.gorylenko.gradle-git-properties" version "1.5.1" }
If you use a Maven build that inherits directly or indirectly from
<properties> <slf4j.version>1.7.5<slf4j.version> </properties>
To override dependency versions in Gradle, see this section of the Gradle plugin’s documentation. The <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> If you do not use the parent POM, you can still use the plugin. However, you must
additionally add an <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>2.0.5.RELEASE</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 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 <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 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: <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 two separate build products,
the executable version has additional configuration files that are not needed in a library
jar. For example, the In Maven, the executable jar must be the main artifact and you can add a classified jar for the library, as follows: <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 that was started with Maven, you
can use the See 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
The following example shows how to build an executable archive with Ant: <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
$ ant -lib <folder containing ivy-2.2.jar> clean manual Then you can run the application with the following command: $ java -jar target/*.jar
|