bootRepackage fails to package dependencies from the new gradle Java Library plugin

Bug report

When using the new Gradle Java Library plugin and declaring dependencies using the api or implementation configurations, the bootRepackage task doesn’t package the dependencies into the final jar.

If I replace the declared dependencies using the compile configuration, then the bootRepackage task does package them into the jar. However, the gradle documentation says to ignore this configuration:

The compile, testCompile, runtime and testRuntime configurations inherited from the Java plugin are still available but are deprecated. You should avoid using them, as they are only kept for backwards compatibility.

Example:

/*
 * This build file was generated by the Gradle 'init' task.
 *
 * This generated file contains a sample Java Library project to get you started.
 * For more details take a look at the Java Libraries chapter in the Gradle
 * user guide available at https://docs.gradle.org/3.5/userguide/java_library_plugin.html
 */

// Apply the java-library plugin to add support for Java Library
apply plugin: 'java-library'
apply plugin: 'org.springframework.boot'

buildscript {
  repositories {
    mavenCentral()
  }

  dependencies {
    classpath "org.springframework.boot:spring-boot-gradle-plugin:1.5.3.RELEASE"
  }
}

// In this section you declare where to find the dependencies of your project
repositories {
    // Use jcenter for resolving your dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}

springBoot {
    mainClass = 'Library'
}

dependencies {
    // This dependency is exported to consumers, that is to say found on their compile classpath.
    api 'org.apache.commons:commons-math3:3.6.1'

    // This dependency is used internally, and not exposed to consumers on their own compile classpath.
    implementation 'com.google.guava:guava:21.0'

    // Use JUnit test framework
    testImplementation 'junit:junit:4.12'
}

[mikepii]

@wilkinsona thank you for posting the workaround, it helped me use the new implementation dependency type in Gradle 4.7 (as compile is deprecated in both the Java plugin and the Java Library plugin). I had to change it to customConfiguration = 'custom' to match the new configuration’s name

[wilkinsona]

The repackaging includes everything in the runtime configuration which is why dependencies in the api and implementation configurations are not being included. 2.0 snapshots are not affected by this problem as the new bootJar task doesn’t deal with configurations directly. Instead, it uses the runtime class path of the main source set.

In 1.5 and earlier, you can configure a custom configuration that will have its dependencies packaged in the jar. Ideally, this would be possible:

bootRepackage {
    customConfiguration = 'implementation'
}

Unfortunately, it fails as Gradle does not allow the implementation configuration to be resolved directly. Instead, you need to introduce some indirection in the form of another configuration that extends implementation:

configurations {
    custom {
        it.extendsFrom implementation
    }
}

bootRepackage {
    customConfiguration = 'implementation'
}

With this in place, both commons-math3 and guava are included in the jar.