Gradle Kotlin DSL 0.10.1 Release Notes

Version 0.10.1 of the Gradle Kotlin DSL, the project formerly known as Gradle Script Kotlin, comes with the latest Kotlin release plus many improvements to usability, stability and performance.

v0.10.1 is expected to be included in the upcoming Gradle 4.1.

WARNING: The base package has been renamed from org.gradle.script.lang.kotlin to org.gradle.kotlin.dsl so you'll need to update any explicit imports after upgrading.

WARNING: Gradle now expects project-schema.json to be found at $ROOT_PROJECT_DIR/gradle/project-schema.json.

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.1-20170707032407+0000-all.zip

Updates since v0.9.1

• Kotlin 1.1.3-2 (#387). Build scripts are now compiled against Kotlin 1.1.3-2.

• Project extension accessors available by default (#397). Before v0.10.1, extension accessors had to be explicitly enabled via a project property, this is no longer the case and accessors for any extensions introduced during the evaluation of the plugins block will be available by default. This means the following Gradle build script will now work as expected without any additional configuration:

  plugins {
      application
  }
  
  application { // application extension accessor
      mainClassName = "my.App"
  }
  

  This behaviour can still be disabled via a Gradle project property:

  org.gradle.kotlin.dsl.accessors=off
  

• Accessors for configurations introduced by applied plugins (#337). Before v0.10.1, the following build script would compile successfully but fail at runtime due to a missing compile configuration:

  dependencies {
      compile("junit:junit:4.12")
  }
  
  repositories {
      jcenter()
  }
  

  That's because the Kotlin DSL exposed a hard-coded set of configuration accessors which were always available regardless of the actual project state.

  In v0.10.1 the same build script will fail to compile because the set of configuration accessors is now computed from the set of project configurations available immediatelly after the plugins block has been evaluated.

• Plugins written in Kotlin can use the same DSL as Kotlin build scripts (#366, #394, #359, #412). Via the new kotlin-dsl plugin:

  plugins {
      `kotlin-dsl`
  }
  

  The plugin is also very handy for organizing build logic under buildSrc.

  The kotlin-dsl plugin will:

  • apply the embedded-kotlin plugin (#392) to ensure Kotlin code gets compiled against the included version of the Kotlin compiler
  • add a dependency on gradleKotlinDsl() thus making the Kotlin DSL extensions available to any Kotlin code
  • configure the Kotlin compiler so org.gradle.api.Action<T> is treated as T.() -> Unit just like it is in build scripts

  Checkout this sample for a demonstration.

• IntelliJ improvements

  • Build script author can navigate to sources of applied plugins and their dependencies (#360)
  • Build script author can navigate to sources of buildscript dependencies (#399)
  • Documentation landing pages for core plugins (#314)

• Performance and Stability

  • Embedded Kotlin dependencies are resolved from distribution (#385)
  • Ensure the latest version of native dependencies appears first in the classpath (#223)

• Miscellaneous

  • Move project-schema.json file to gradle/project-schema.json (#398)
  • Simplified extra property initialization (#307)
  • Additional Groovy Closure interoperability helpers (#350)
  • Updated Android sample (#351). The sample has been updated to work with Android Studio 2.3.3 (build #AI-162.4069837, 06 Jun 2017 00:00) running Kotlin 1.1.3-release-Studio2.3-2.
  • Plugin accessor for the build-scan plugin (#404)
  • Existing collection element can be explicitly referenced and configured via delegated property (#407)

    collection {
    
        // referencing existing with default type
        val existing by getting
    
        // referencing existing with non default type
        val existing: Foo by getting
    
        // configuring existing with default type
        val existing by getting {
            property = value
        }
    
        // configuring existing with non default type
        val existing by getting(Foo::class) {
            fooProperty = value
        }
    }