64.7 Repackage with custom Gradle configuration
Sometimes it may be more appropriate to not package default dependencies resolved from compile
, runtime
and provided
scopes. If the created executable jar file is intended to be run as it is, you need to have all dependencies nested inside it; however, if the plan is to explode a jar file and run the main class manually, you may already have some of the libraries available via CLASSPATH
. This is a situation where you can repackage your jar with a different set of dependencies.
Using a custom configuration will automatically disable dependency resolving from compile
, runtime
and provided
scopes. Custom configuration can be either defined globally (inside the springBoot
section) or per task.
task clientJar(type: Jar) { appendix = 'client' from sourceSets.main.output exclude('**/*Something*') } task clientBoot(type: BootRepackage, dependsOn: clientJar) { withJarTask = clientJar customConfiguration = "mycustomconfiguration" }
In above example, we created a new clientJar
Jar task to package a customized file set from your compiled sources. Then we created a new clientBoot
BootRepackage task and instructed it to work with only clientJar
task and mycustomconfiguration
.
configurations { mycustomconfiguration.exclude group: 'log4j' } dependencies { mycustomconfiguration configurations.runtime }
The configuration that we are referring to in BootRepackage
is a normal Gradle configuration. In the above example we created a new configuration named mycustomconfiguration
instructing it to derive from a runtime
and exclude the log4j
group. If the clientBoot
task is executed, the repackaged boot jar will have all dependencies from runtime
but no log4j
jars.
64.7.1 Configuration options
The following configuration options are available:
Name | Description |
---|---|
mainClass |
The main class that should be run by the executable archive. |
providedConfiguration |
The name of the provided configuration (defaults to providedRuntime ). |
backupSource |
If the original source archive should be backed-up before being repackaged (defaults to true ). |
customConfiguration |
The name of the custom configuration. |
layout |
The type of archive, corresponding to how the dependencies are laid out inside (defaults to a guess based on the archive type). See available layouts for more details. |
requiresUnpack |
A list of dependencies (in the form “groupId:artifactId” that must be unpacked from fat jars in order to run. Items are still packaged into the fat jar, but they will be automatically unpacked when it runs. |
64.7.2 Available layouts
The layout
attribute configures the format of the archive and whether the bootstrap loader should be included or not. The following layouts are available:
Name | Description | Executable |
---|---|---|
JAR |
Regular executable JAR layout. | Yes |
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. |
Yes |
ZIP (alias to DIR ) |
Similar to JAR layout, using PropertiesLauncher . |
Yes |
MODULE |
Bundle dependencies (excluding those with provided scope) and project resources. |
No |
NONE |
Bundle all dependencies and project resources. | No |