Gradle Kotlin DSL 0.12.0 Release Notes

Gradle Kotlin DSL v0.12.0 brings the latest and greatest Kotlin (1.1.51), runs on Java 9, has better support for Kotlin dependencies and more.

v0.12.0 is expected to be included in the upcoming Gradle 4.3 RC1.

The features in this release are also available for immediate use within the latest Gradle Kotlin DSL distribution snapshot. To use it, upgrade your Gradle wrapper in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-distribution-url https://repo.gradle.org/gradle/kotlin-dsl-snapshots-local/gradle-kotlin-dsl-4.3-20171004164220+0000-all.zip

Once Gradle 4.3 RC1 is out, we encourage all users to upgrade in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 4.3-rc-1 --distribution-type all

Breaking changes

Starting with this release, kotlin("...") plugin requests no longer default to embeddedKotlinVersion and so build scripts that rely on that behavior must be changed to include an explicit version number otherwise they will fail.

For a concrete example, the following simple build script that applies the kotlin("jvm") plugin without specifying a version number will now fail:

// build.gradle.kts
plugins {
    kotlin("jvm")
}

$ ./gradlew tasks
FAILURE: Build failed with an exception.

* What went wrong:
Plugin [id: 'org.jetbrains.kotlin.jvm'] was not found in any of the following sources:

...

The solution is to include a version number:

// build.gradle.kts
plugins {
    kotlin("jvm") version "1.1.51"
}

Notice that in a multi-project setup, the version number for plugins used in multiple projects should be specified only once in a common ancestor project, possibly the root as it's done in this sample.

Updates since v0.11.1

• Kotlin 1.1.51 (#473). The embedded Kotlin version was upgraded from Kotlin 1.1.4-3 to the latest Kotlin 1.1.51 release, an update to Kotlin 1.1.50.

• Kotlin based build scripts run on Java 9 :tada: (#454, #493). Thanks in large part to the great Gradle Kotlin DSL community and Jonathan Leitschuh in particular who pushed the necessary changes and testing forward. Thank you!

• More use-cases supported by the plugins block (#426). Specifically, plugins already available in the classpath can now be applied via the plugins block thus enabling the following use cases:

  1. Plugin defined in buildSrc can be applied by id

     // root/buildSrc/src/main/kotlin/build/MyPlugin.kt
     package build
     
     import org.gradle.api.*
     
     open class MyPlugin : Plugin<Project> {
     
         override fun apply(project: Project) {
             // ...
         }
     }
     

     // root/buildSrc/build.gradle.kts
     plugins {
         `kotlin-dsl`
         `java-gradle-plugin`
     }
     
     gradlePlugin {
         (plugins) {
             "my-plugin" {
                 id = "my-plugin"
                 implementationClass = "build.MyPlugin"
             }
         }
     }
     

     // root/build.gradle.kts
     plugins {
         id("my-plugin")
     }
     

  2. Plugin applied to parent project can be applied in child projects

     // root/build.gradle.kts
     plugins {
         id("foo") version "1.0"
     }
     

     // root/sub/build.gradle.kts
     plugins {
         id("foo")
     }
     

  3. Plugin requested but not applied on parent can be applied in child projects

     // root/build.gradle.kts
     plugins {
         id("foo") version "1.0" apply false
     }
     

     // root/sub/build.gradle.kts
     plugins {
         id("foo")
     }
     

• Improved documentation. The Configuring Plugins in the Gradle Kotlin DSL documentation section was revamped to account for the new capabilities in Gradle and the Gradle Kotlin DSL. The API documentation has also been updated to match this release.

• kotlin("...") plugin request no longer defaults to embeddedKotlinVersion (#520, #521)

  Given that it is now possible to use the plugins block in child projects to apply plugins already requested on a parent project, the following idiom becomes possible:

  // root/build.gradle.kts
  plugins {
      // Decide version of plugin in the root project
      kotlin("jvm") version "1.1.51" apply false
  }
  

  // root/child/build.gradle.kts
  plugins {
      kotlin("jvm") // Reuse version defined by parent
  }
  

  In order to enable that use-case kotlin("jvm") will no longer imply version embeddedKotlinVersion.

  Unfortunately this is a breaking change as the version will now have to be specified at least once at the top most project.

• kotlin("...") dependency notation no longer defaults to embeddedKotlinVersion (#511). The version of Kotlin artifact dependencies will be set by the Kotlin Gradle plugin as explained in the Using Gradle section of the Kotlin reference guide :

  Starting with Kotlin 1.1.2, the dependencies with group org.jetbrains.kotlin are by default resolved with the version taken from the applied plugin. You can provide the version manually using the full dependency notation.

• Richer and more consistent DependencyHandler API (#291). For configurations known at plugin application time and otherwise as demonstrated by the following screenshots:

  • Extensions for configurations known at plugin application time

    

  • String.invoke extensions (for addressing configurations by name)

    

  • Configuration.invoke extensions (for Configuration references already in scope)

    

• Expose groovy builder delegate (#503). So it can be explicitly passed as an argument, for example when configuring mavenDeployer:

  mavenDeployer {
      withGroovyBuilder {
          "beforeDeployment" {
              if (signing.required)
                  signing.signPom(delegate as MavenDeployment)
          }
      }
  }
  

• Nullable extra properties (#516, #512). Nullable extra properties can now be expressed via nullability of the property type:

  val name by extra { null } // creates null extra property
  
  val name: String by extra  // throws NPE on property usage
  val name: String? by extra // works as expected
  

• Implicit imports comply with the Gradle core public API definition (#483)

  • By disambiguating simple type names amongst types with the same simple name in different Gradle API packages. For example, resolving Jar to the correct type. Previously wildcard implicit imports failed to resolve Jar as it matches both org.gradle.api.tasks.bundling.Jar and org.gradle.jvm.tasks.Jar forcing the use of explicit imports. With the new behaviour Jar will be resolved to org.gradle.jvm.tasks.Jar as specified by Gradle.

  • By no longer including the internal org.gradle.util package in the set of implicit imports.

• New sample demonstrating how to build a simple Javascript application written in Kotlin (#470, #478). The sample can be found in samples/hello-js.

• Android sample now uses the plugins block to apply android and kotlin plugins (#406). Which makes it easier to configure the project by removing the need to generate the gradle/project-schema.json file.

  A plugin resolution strategy is used to substitute plugin requests for id("com.android.application") by the actual Android Gradle Plugin artifact. This strategy also works with the upcoming Android Gradle Plugin 3.

  The sample can be found in samples/hello-android.

• kotlin-dsl plugin no longer declares redundant runtime Kotlin dependency (#509, #510). The embedded-kotlin plugin, applied by kotlin-dsl will now add the kotlin-stdlib and kotlin-reflect dependencies to the compileOnly and testCompileOnly configurations instead of compile.

• Dollar sign in extension or configuration names no longer cause build script compilation errors (#494)

• IntelliJ improvements

  • KT-19310 Intellij can't resolve inner types in plugin class in build.gradle.kts files (#417)
  • KT-19466 Kotlin based Gradle build not recognized when added as a module (#188)
  • KT-18889 Cannot navigate to source of overloaded property setter (#409)
  • KT-18890 Cannot navigate to source of method accepting SAMWithReceiver argument (#410)