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

results matching ""

    No results matching ""