Gradle Kotlin DSL 1.0 RC1 Release Notes

Gradle Kotlin DSL 1.0 RC1 brings Kotlin 1.2.60, support for configuration avoidance, a Gradle API decorated for Kotlin, enhanced IntelliJ IDEA integration, lots of DSL polish and bug fixes.

At the same time the IntelliJ IDEA Kotlin Plugin fixed important build script editing related issues. It is recommended for everyone to upgrade to the latest and greatest.

This release contains potential breaking changes, see below.

v1.0-RC1 is included in Gradle 4.10 RC1.

To use it, upgrade your Gradle wrapper in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 4.10-rc-1

Gradle Kotlin DSL 1.0 will ship with the next version of Gradle.

Updates since v0.18.4

• Documentation (#665, #835, #966, #968, #988) All public Gradle Kotlin DSL API members now have proper documentation available in the IDE and in the API reference.

  

  You might also want to check out the guide to migrating build logic from Groovy to Kotlin and other Gradle guides that now contain samples for the Gradle Kotlin DSL.

• Script compilation build cache (#963, #978, #987) Compiled project scripts can now be cached in a shared Gradle build cache for maximum reuse across builds. The experimental build cache integration must be explicitly enabled via the org.gradle.kotlin.dsl.caching.buildcache Gradle project property set to true.

• Script compilation now targets JVM 8 (#955, #955) As a result, it is now possible to use libraries targeting JVM 8 in your build scripts.

• IDE integration improvements (#962, #972, #942, #464, #1004) When editing build logic in IntelliJ IDEA, changes are now propagated between scripts and between buildSrc and scripts without having to sync the Gradle build, resulting in a much better user experience.

  

  The lifecycle of Gradle daemons spawned by IntelliJ IDEA when editing Gradle Kotlin DSL script has been revised to prevent running too many of them. Before that change and under certain circumstances, one Gradle daemon was running per open script, this is now limited, resulting in less pressure on the system and a quicker feedback.

  Moreover, all usages of types relying on kotlin implementation by delegation for a Java interface now show meaningful parameter name hints instead of p0, p1 etc..:

  

• Support for configuration avoidance of named domain object containers (#123, #907, #986, #993, #994, #1000) Gradle 4.9 introduced new APIs for declaring and configuring Gradle Tasks in build scripts and plugins that allow Gradle to avoid executing unnecessary build logic. Gradle 4.10 makes the same API available for all NamedDomainObjectContainer types.

  This release of the Gradle Kotlin DSL promotes these APIs as the preferred way of configuring container elements by

  • reimplementing the String invoke DSL sugar plus the getting and creating delegated properties atop the new APIs ;
  • introducing the new existing and registering delegated properties designed specifically with configuration avoidance in mind which expose NamedDomainObjectProvider<T> instead of the container element type.

  As an example, let's look at wiring a simple task graph using only the new configuration avoidance support.

  /**
   * An example Gradle task.
   */
  open class GreetingTask : DefaultTask() {
  
      val message = objects.property<String>()
  
      @TaskAction
      fun greet() = println(message.get())
  }
  
  tasks {
  
      // `hello` is a `TaskProvider<GreetingTask>`
      val hello by registering(GreetingTask::class) {
          message.set("Hello!")
      }
  
      // `goodbye` is a `TaskProvider<GreetingTask>`
      val goodbye by registering(GreetingTask::class)
  
      // Every `NamedDomainObjectProvider<T>` can be lazily configured as follows
      goodbye {
          dependsOn(hello)
      }
  
      // Existing container elements can be lazily configured via the `String` invoke DSL
      "goodbye"(GreetingTask::class) {
          message.set("Goodbye!")
      }
  
      // Regular API members are also available
      register("chat")
  }
  
  // ...
  
  tasks {
  
      // Existing container elements can be lazily brought into scope
      val goodbye by existing
  
      "chat" {
          dependsOn(goodbye)
      }
  }
  

• SAM conversion for Kotlin functions (#522, #960) SAM (Single Abstract Method) conversion for Kotlin functions allows Kotlin build logic to expose and consume org.gradle.api.Action<T> based APIs. Such APIs can then be used uniformly from both the Kotlin and Groovy DSLs.

  As an example, given the following hypothetical Kotlin function with a Java SAM parameter type:

  fun kotlinFunctionWithJavaSam(action: org.gradle.api.Action<Any>) = TODO()
  

  SAM conversion for Kotlin functions enables the following usage of the function:

  kotlinFunctionWithJavaSam {
      // ...
  }
  

  Without SAM conversion for Kotlin functions one would have to explicitly convert the passed lambda:

  kotlinFunctionWithJavaSam(Action {
      // ...
  })
  

• Gradle API is decorated for Kotlin (#221, #914) The public Gradle API available in Gradle Kotlin DSL scripts and Kotlin sources of projects applying the kotlin-dsl plugin is now decorated with Kotlin extensions mapping java.lang.Class<?> function parameters to kotlin.reflect.KClass<?> parameters.

  As an example, the following settings file:

  buildCache {
      remote(HttpBuildCache::class.java) {
          url = uri("http://example.com/cache")
      }
  }
  

  can now be written omitting .java:

  buildCache {
      remote(HttpBuildCache::class) {
          url = uri("http://example.com/cache")
      }
  }
  

For the complete list see the gradle/kotlin-dsl issues for 1.0-RC1.

Breaking changes

This release contains some potential breaking changes:

• Container String invoke now is register() instead of maybeCreate()

• SAM conversion for Kotlin functions is now enabled The now enabled Kotlin compiler features could cause Gradle Kotlin DSL scripts or code in projects applying the kotlin-dsl plugin that previously compiled successfully to fail. The now stricter type inference semantics might cause types previously inferred as non-null to be inferred as nullable, for example. At the same time, it can cause previously unambiguous call sites to become ambiguous and will need to be disambiguated. See the Kotlin compiler arguments section of the Gradle Kotlin DSL documentation for more information about the enabled Kotlin compiler features.

• The named containers API signature changed As a result, a plugin using e.g. delegated properties providers getting or creating, compiled against this release will fail when run with previous Gradle Kotlin DSL versions.

• The kotlin-dsl plugin now respect the JSR-305 package annotations Just like the Gradle Kotlin DSL scripts do. As a result, annotated Java elements whose types were previously seen as Kotlin platform types, thus non-nullable, will now be seen as effectively either non-nullable or nullable types depending on the JSR-305 annotations. This change could cause compilation errors in projects applying the kotlin-dsl plugin. See Calling Java code from Kotlin in the Kotlin documentation for more information.

Gradle Kotlin DSL 0.18.4 Release Notes

Gradle Kotlin DSL 0.18.4 brings faster and leaner configuration time, enhanced IntelliJ IDEA integration and bug fixes.

At the same time the IntelliJ IDEA Kotlin Plugin fixed important build script editing related issues. It is recommended for everyone to upgrade to the latest and greatest.

v0.18.4 is included in Gradle 4.9 RC1.

To use it, upgrade your Gradle wrapper in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 4.9-rc-1

Updates since v0.17.5

• Faster and leaner configuration time (#887, #897, #833, #922) After the fix of the most outstanding configuration time hotspots in v0.17.x, this release includes more performance improvements and drastic changes to the Kotlin DSL provider structure to avoid work when possible and make it even more efficient. For the gradle/gradle build that meant a ~100ms faster configuration time, going from ~1.5s down to ~1.4s.

  In red, Gradle 4.9 with Kotlin DSL 0.17.x. In blue, Gradle 4.9 with Kotlin DSL 0.18.x. See this graph in situ.

  Other synthetic benchmarks shown 20% improvements or more in specific scenarios:

  samples/plugins-block-only (applies the java plugin using the plugins block)
          baseline: 41.68 ms    42.76 ms (std dev 14.56 ms)
          latest:   33.35 ms    35.69 ms (std dev 8.27 ms)
          latest / baseline: 0.80
  
  samples/plugins-block-with-script (applies the java plugin then configures it)
          baseline: 43.34 ms    44.12 ms (std dev 13.63 ms)
          latest:   33.54 ms    35.26 ms (std dev 6.17 ms)
          latest / baseline: 0.77
  

• Script dependencies resolution errors and warnings reported in IntelliJ IDEA (#151) IntelliJ IDEA editor for Gradle Kotlin DSL scripts will now display a warning or error when the resolution of the edited script dependencies encounter failures instead of failing silently.

  

• Allow for multiple extensions of the same parameterized type (#905) Before this release when there were multiple extensions of the same parameterized type such as NamedDomainObjectContainer<T> defined for a project, then the generated accessors would conflict causing a script compilation failure.

  It is now possible to register multiple extensions of the same parameterized type.

• gradle --version now displays Gradle Kotlin DSL and Kotlin versions (#481)

  ------------------------------------------------------------
  Gradle 4.9-rc-1
  ------------------------------------------------------------
  
  Build time:   <date>
  Revision:     <commit-hash>
  
  Kotlin DSL:   0.18.4
  Kotlin:       1.2.41
  Groovy:       2.4.12
  Ant:          Apache Ant(TM) version 1.9.11 compiled on March 23 2018
  JVM:          1.8.0_161 (Oracle Corporation 25.161-b12)
  OS:           Mac OS X 10.13.4 x86_64
  

For the complete list see the gradle/kotlin-dsl issues for 0.18.x.

Gradle Kotlin DSL 0.17.5 Release Notes

Gradle Kotlin DSL v0.17.5 fixes two issues identified after the v0.17.4 release.

v0.17.5 is included in Gradle 4.8 RC2.

To use it, upgrade your Gradle wrapper in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 4.8-rc-2 --distribution-type all

Fixes since v0.17.4

• Fix IDE classpath computation for script plugins with buildscript {} dependencies (gradle/kotlin-dsl#110)
• Fix wrong in-memory script compilation cache hits (gradle/kotlin-dsl#844)

Breaking changes

There are no breaking changes upgrading from 0.17.4 to 0.17.5.

Gradle Kotlin DSL 0.17.4 Release Notes

Gradle Kotlin DSL 0.17.4 brings Kotlin 1.2.41 and many improvements to the user experience including location aware runtime error reporting, convenient configuration of nested extensions, faster and leaner configuration time and TestKit support.

At the same time the IntelliJ IDEA Kotlin Plugin fixed many long standing build script editing related issues. It is recommended for everyone to upgrade to the latest and greatest.

v0.17.4 is included in Gradle 4.8 RC1.

To use it, upgrade your Gradle wrapper in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 4.8-rc-1

Updates since v0.16.3

• Kotlin 1.2.41 (#830) The embedded Kotlin version was upgraded from Kotlin 1.2.31 to the latest official release, Kotlin 1.2.41.

• Faster and leaner configuration time (#824) Thanks to our great performance testing infrastructure we were able to find and fix the most outstanding hotspots in configuration time contributed by the Kotlin DSL provider. For the gradle/gradle build that meant 6% faster and 25% less memory hungry configuration time.

• Convenient configuration of nested extensions (#457, #343) Although a relatively uncommon pattern, project extensions can themselves be extended. Before this release such extensions could only be found by either looking at the plugins documentation or source. Starting with this release, the Kotlin DSL provides accessors for nested extensions found after plugins application. Making them discoverable from the IDE.

  For example, the com.github.jacobono.jaxb exposes a jaxb extension which is then extended with a xjc extension:

  plugins {
      id("com.github.jacobono.jaxb") version "1.3.5"
  }
  
  jaxb {
      xsdDir = "src/xsd"
      xjc {
          destinationDir = "src/generated/java"
      }
  }
  

• Gradle TestKit support (#492) A long standing issue that was preventing the use of the Gradle TestKit to its full extent with Kotlin DSL builds is fixed in this release.

  See the testkit sample that demonstrates how to test Kotlin DSL builds with TestKit.

• Support for the buildscript {} block in applied scripts (#180) Applied scripts can now declare dependencies to libraries and plugins using the buildscript {} block.

  The modularity sample has been updated to demonstrate how to add dependencies to applied scripts.

  IDE support for buildscript dependencies is still lacking and it will be implemented in the next release. See #110.

• Cleaner script runtime error reporting (#791) While 0.15.6 included proper script compilation error reporting, this release brings the same experience for runtime errors. It is not more needed to scroll up the log to see what failed, the errors are displayed in context to make diagnosing the cause easier and allow IDEs to provide links to the offending source:

  

• JSR-305 package annotations enabled by default (#463) Kotlin 1.1.4 introduced support for package-default nullability annotations. Starting with this release JSR-305 annotations are automatically enabled for Gradle Kotlin DSL scripts. Allowing Kotlin scripts to take advantage of the nullability information present in any referenced library, including the Gradle API of course.

• Gradle live collections API refinements (#804) The block syntax for Gradle collections has been expanded to support the whole PolymorphicDomainObjectContainer API and reified generic versions of the corresponding members were added.

  tasks {
  
      create<Greet>("greet")
  
      maybeCreate<Greet>("greet")
  
      getByName<Greet>("greet") {
          message = "Hello from getByName!"
      }
  
      create<Greet>("greet-again") {
          message = "Hello from create!"
      }
  }
  
  open class Greet : DefaultTask() {
  
      @Input
      var message = "Hello!"
  
      @TaskAction
      fun greet() = println(message)
  }
  

• Android sample updated to Android Studio 3.1 (#808) The Android sample has been updated to Android Studio 3.1 and now reflects the multi-project structure that Studio creates by default. This Studio release makes it possible to finally use only Kotlin DSL build scripts. It is no more needed to keep some Groovy scripts around.

Plus some other API additions, enhancements and bug fixes. For the complete list see the gradle/kotlin-dsl issues for 0.17.x.

Breaking changes

This release contains some potential breaking changes:

• The Kotlin DSL now respects the JSR-305 package annotations As a result, annotated Java elements whose types were previously seen as Kotlin platform types, thus non-nullable, will now be seen as effectively either non-nullable or nullable types depending on the JSR-305 annotations. This change could cause script compilation errors.

• The named containers API signature changed As a result, a plugin using e.g. delegated properties providers getting or creating, compiled against this release will fail when run with previous Gradle Kotlin DSL versions.

Gradle Kotlin DSL 0.16.3 Release Notes

Gradle Kotlin DSL v0.16.3 brings Kotlin 1.2.31, support for .gradle.kts scripts in Kotlin source sets, Java 10, a more consistent API, better IntelliJ IDEA integration, and further improved parity with the Groovy DSL.

v0.16.3 is included in Gradle 4.7 RC1.

To use it, upgrade your Gradle wrapper in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 4.7-rc-1

Updates since v0.15.6

• Kotlin 1.2.31 (#738) The embedded Kotlin version was upgraded from Kotlin 1.2.21 to the latest official release, Kotlin 1.2.31.

• Precompiled script plugins (#666, #667, #668, #669, #670).

  In our continued effort to make it easier to author, reuse and share Gradle build logic, this release introduces the ability to publish Kotlin scripts as binary Gradle plugins with very low ceremony, a feature we are tentatively calling precompiled script plugins.

  A precompiled script plugin is a Kotlin script compiled as part of a regular Kotlin source-set, meant to be consumed as a binary Gradle plugin whose identifier is automatically derived from its file name and optional package declaration.

  The feature is enabled via the PrecompiledScriptPlugins plugin in combination with the java-gradle-plugin and kotlin-dsl plugins:

  plugins {
      `java-gradle-plugin`
      `kotlin-dsl`
  }
  
  apply<org.gradle.kotlin.dsl.plugins.precompiled.PrecompiledScriptPlugins>()
  

  After which *.gradle.kts scripts under src/main/kotlin would be automatically exposed as Gradle plugins.

  For example, in the project below, the Kotlin script src/main/kotlin/my-plugin.gradle.kts is automatically exposed as the my-plugin Gradle plugin and could be applied to a Gradle build in the usual ways.

  

  And while there are several limitations which we plan to address in subsequent releases, we expect the current feature-set to be compelling enough for self-contained plugins.

  To learn more about precompiled script plugins please check out the precompiled-script-plugin sample.

• Unified DSL for Gradle/Project and extra properties (#626).

  The DSL to access Gradle/Project properties and extra properties via Kotlin delegated properties is now unified with support for typed access and optionality encoding using Kotlin nullable types across the board.

  val some: String by project
  val optional: String? by project
  val other: Int by extra
  val otherOptional: Int? by extra
  

  The change to delegated properties to access Gradle/Project properties is potentially breaking, please see the Breaking changes section below for more detailed information.

• Access to Gradle properties in settings scripts (#653).

  It is now possible to access Gradle properties in settings scripts just like Project properties in build scripts:

  val some: String by settings
  val optional: String? by settings
  

• the<T>() and configure<T> {} enhancements (#703, #319).

  Those extensions are now available on all ExtensionAware objects, not only Project. This allows to configure e.g. Task extensions:

  tasks {
      "test"(Test::class) {
          configure<JacocoTaskExtension> {
              isAppend = true
          }
      }
  }
  

  This is a potential breaking change, please see the Breaking changes section below for what to expect when upgrading.

  In addition to the above, the<T>() and configure<T> {} now support nested generics queries using Kotlin reified types. This allows to request extensions by type such as NamedDomainObjectContainer<Thing>.

• Support for cross-configuring buildscript {} (#374).

  In build scripts:

  project(":sub") {
      buildscript {
          // ...
      }
  }    
  

  In settings scripts:

  gradle.projectsLoaded {
      rootProject.buildscript {
          // ...
      }
  }
  

  In initialization scripts:

  projectsLoaded {
      rootProject.buildscript {
          // ...
      }
  }
  

Plus some other API additions, enhancements and bug fixes. For the complete list see the gradle/kotlin-dsl issues for 0.16.x.

Breaking changes

This release contains several potential breaking changes:

• Access to Gradle/Project properties via Kotlin delegated properties now requires property type declaration

  If your build was accessing Project properties in the following fashion:

  val some by Project
  

  you'll now get a compilation error:

  Script compilation error:
  
    Line 2: val some by project
                        ^ Property delegate must have a 'getValue(Build_gradle, KProperty<*>)' method. None of the following functions is suitable:
                            public abstract operator fun <T> getValue(receiver: Any?, property: KProperty<*>): ??? defined in org.gradle.kotlin.dsl.PropertyDelegate
  

  It is now required that you strongly type the property as follows:

  val some: String by Project
  

  If the property is optional you can express it using a Kotlin nullable type:

  val some: String? by Project
  

• Erroneous usage of the plugins {} block in a nested scope now throws, it was a no-op before

  The plugins {} block can only be used as a top-level expression, but, the API is available in nested scopes. Starting with this release, if you use the plugins {} block in a nested scope, for example:

  subprojects {
      plugins {
          // ...
      }
  }
  

  you'll now get a build failure as follows:

  The plugins {} block must not be used here. If you need to apply a plugin imperatively, please use apply<PluginType>() or apply(plugin = "id") instead.
  

• the<T>() and configure<T> {} are now available on all ExtensionAware types

  Before this release those two extensions were only available on the Project type. This release makes them available on all ExtensionAware types such as Task, for example. That might cause the wrong ExtensionAware object to be selected as the receiver for the operations in contexts where another ExtensionAware instance is available in a closer scope. Take the following code as an example:

  tasks {
      "foo" {
        // the<T>() and configure<T> {} mean something different here in the new release
      }
  } 
  

  This change can lead to two different behaviors depending on the requested type.

  If the requested extension type is not available to the now selected ExtensionAware you'll get the following error:

  Extension of type 'RequestedType' does not exists. Currently registered extensions types: [...]
  

  If the requested extension type is also available to the now selected ExtensionAware your script will configure the extension on a different object, changing your build behavior.

• It is now enforced that there's a single pluginManagement {} block in settings scripts

  If you happen to have more than one pluginsManagement {} block in your settings script you will now get the following error:

  Unexpected `pluginManagement` block found. Only one `pluginManagement` block is allowed per script.
  

Gradle Kotlin DSL 0.15.6 Release Notes

Gradle Kotlin DSL v0.15.6 brings Kotlin 1.2.21, initialization scripts support, cleaner script compilation error reporting, performance improvements and better IntelliJ IDEA integration.

v0.15.6 is included in Gradle 4.6 RC1.

To use it, upgrade your Gradle wrapper in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 4.6-rc-1

Breaking changes

Starting with this release, Gradle Kotlin DSL depends on kotlin-stdlib-jdk8 instead of kotlin-stdlib-jre8. See what's new in Kotlin 1.2 for more information.

Updates since v0.14.2

• Initialization scripts support (#123). Gradle initialization scripts can now be written in Kotlin. Editing support in IntelliJ IDEA is available starting with the Kotlin IntelliJ Plugin 1.2.30-eap-47: IMPORTANT: IntelliJ IDEA differentiates an initialization script from a regular build script by its file name which must end with .init.gradle.kts.

• Cleaner script compilation error reporting (#123). Script compilation errors are now reported properly by Gradle, no need to scroll up the log to see what failed, and they are displayed in context to make diagnosing the cause easier:

• Performance improvements (#696, #707). The new in-memory script cache significantly increases the amount of avoided work when reusing a Gradle daemon or applying the same script more than once in a single build.

• Kapt sample (#616). A new sample demonstrating the usage of Kapt on a Kotlin project was introduced.

• IntelliJ IDEA improvements

  • (#715) Generated static accessors are now available when editing buildSrc/build.gradle.kts.
  • (#714) Editor will no longer discard the script classpath when facing errors greatly reducing the probability of "whole file red" situations. To get the most out of this change upgrade to IntelliJ Kotlin Plugin >= 1.2.30-eap-47.

Plus some API additions and bug fixes. For the complete list see the gradle/kotlin-dsl issues for 0.15.x.

Gradle Kotlin DSL 0.14.2 Release Notes

Gradle Kotlin DSL v0.14.2 fixes a regression identified after the v0.14.0 release.

v0.14.2 is included in Gradle 4.5 RC1.

To use it, upgrade your Gradle wrapper in the following fashion:

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

Breaking changes

There are no breaking changes upgrading from 0.14.0 to 0.14.2.

Fixes since v0.14.2

• Fix regression on applying Kotlin script from buildscript block (gradle/gradle#3759)

Gradle Kotlin DSL 0.13.2 Release Notes

Gradle Kotlin DSL v0.13.2 fixes a regression in v0.13.1 that prevented the use of nested Kotlin build scripts together with the --scan command line option.

v0.13.2 will be included in the upcoming Gradle 4.4.1.

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.4-20171208150335+0000-all.zip

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

To use it, upgrade your Gradle wrapper in the following fashion:

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 4.4.1 --distribution-type all

Breaking changes

There are no breaking changes upgrading from 0.13.1 to 0.13.2.

Fixes since v0.13.1

• Plugin with id 'com.gradle.build-scan' not found (gradle/gradle#3759).

Gradle Kotlin DSL 0.14.0 Release Notes

Gradle Kotlin DSL v0.14.0 brings the latest and greatest Kotlin 1.2, improved interoperability with Groovy plugins and more.

v0.14.0 will be included in Gradle 4.5.

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.5-20171202002741+0000-all.zip

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

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

Breaking changes

There are no breaking changes upgrading from 0.13.1 to 0.14.0.

Updates since v0.13.1

• Kotlin 1.2 (#617, #526). The embedded Kotlin version was upgraded from Kotlin 1.1.51 to the latest Kotlin 1.2 release.

• Improved Groovy interop with null receiving closures (#594). Thanks to @JLLeitschuh it's now much easier to interact with plugins that expect Groovy closures that either accept or return null.

• Navigation to Gradle sources in IDEA with a -bin distribution (#604). Previously, the Kotlin DSL runtime expected an -all Gradle distribution to be used in order to enable navigation to the Gradle sources. When this distribution wasn't used (typically with the wrapper) navigating to Gradle sources wasn't possible. Starting with this release, whenever the Gradle sources are not available locally, the Kotlin DSL runtime will do its best to download a compatible source distribution and make it available to the IDE for navigation.

• Android sample update (#586). Now on Android Gradle Plugin 3.0.1.

Gradle Kotlin DSL 0.13.1 Release Notes

Gradle Kotlin DSL v0.13.1 brings support for settings.gradle.kts files, Kotlin standard library extensions to the Java 7 and Java 8 APIs for use in build scripts, improvements to the plugins {} DSL, and more!

v0.13.1 is included in Gradle 4.4 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.4-20171117171149+0000-all.zip

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

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

Breaking changes

There are no breaking changes upgrading from 0.12.3 to 0.13.1.

Updates since v0.12.3

• Support settings file written in Kotlin (#56). Gradle will now look for a file named settings.gradle.kts whenever settings.gradle cannot be found during the initialization phase. settings.gradle.kts is evaluated against the Gradle Settings object so all of its members can be referenced without qualification. In addition, all members of the ScriptApi interface are supported and can also be referenced without qualification. Support for authoring settings.gradle.kts landed on IntelliJ IDEA starting with version 1.1.60-eap-43 of the Kotlin plugin (#531):

  

  All samples have been updated to take advantage of settings.gradle.kts support (#550) and new samples have been added demonstrating how to use settings.gradle.kts to configure:

  • the build cache (#570, sample)
  • dependency substitutions in composite builds (#571, sample)
  • source dependencies (#572, sample)

• Default build-scan plugin version is the same as the one applied by Gradle when the --scan option is specified (#490). Prior to this release, the default version of the build-scan plugin was hard-coded in the kotlin-dsl distribution. That information is now managed by Gradle Core.

• Expose Kotlin standard library extensions for Java 7 and Java 8 to build scripts (#558). The build script classpath now includes kotlin-stdlib-jre8 and kotlin-stdlib-jre7 enabling the use of features such as named regex groups, kotlin.streams among other things.

• Android sample update (#586). Now on Android Gradle Plugin 3.0.0 thanks to @liutikas. Thank you, @liutikas!

• kotlin2js plugin sample updated to leverage the plugins block (#539).

• Account for PropertyState deprecation in favor of Property (#540). org.gradle.api.provider.PropertyState has been deprecated in favour of org.gradle.api.provider.Property. Samples and API extensions have been updated to take the change into account.