0.12.3

Gradle Kotlin DSL 0.12.3 Release Notes

Gradle Kotlin DSL v0.12.3 is the final update to the v0.12.0 release fixing a breaking change to Kotlin build scripts using the Property API.

v0.12.3 is already included in Gradle 4.3 RC4.

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

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

Breaking changes

Please check out the v0.12.0 release notes for details.

Fixes since v0.12.2

• Rename of org.gradle.api.provider.PropertyState to org.gradle.api.provider.Property caused a loss in DSL extension function (#574). The extension members previously only available to org.gradle.api.provider.PropertyState are now also available to org.gradle.api.provider.Property.

0.12.2

Gradle Kotlin DSL 0.12.2 Release Notes

Gradle Kotlin DSL v0.12.2 is another minor update to the v0.12.0 release, this time with a fix for a defect identified during the Gradle RC2 testing phase.

v0.12.2 is already included in Gradle 4.3 RC3.

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

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

Breaking changes

Please check out the v0.12.0 release notes for details.

Fixes since v0.12.1

• Auto-applied build scan plugin not found when used in Kotlin DSL (#3250). Executing Gradle with the --scan command line option in a project where the main build script contains a buildscript block that applies other scripts would cause the build to fail as described in the issue. This has been fixed.

0.12.1

Gradle Kotlin DSL 0.12.1 Release Notes

Gradle Kotlin DSL v0.12.1 is a minor update to the v0.12.0 release with better support for the build-scan plugin.

v0.12.1 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-20171010191714+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

Please check out the v0.12.0 release notes for details.

Updates since v0.12.0

• Upgrade build-scan plugin version to 1.9.1 (#533). The build-scan plugin dependency version will now default to 1.9.1.

• Automatically apply the build-scan plugin when --scan is provided on the command-line (#532). Starting with Gradle 4.3 it is now possible to produce a build scan without explicitly applying the build-scan plugin via the --scan command-line argument.

0.12.0

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 🎉 (#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 sam...

0.11.1

Gradle Kotlin DSL 0.11.1 Release Notes

Gradle Kotlin DSL v0.11.1 brings the latest and greatest Kotlin (1.1.4-3) and takes big steps toward general usability with utilities for Groovy-heavy DSLs such as Maven POM customization, Ant usage and those provided by Groovy-biased community plugins.

v0.11.1 is expected to be included in the upcoming Gradle 4.2 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.2-20170901130305+0000-all.zip

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

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

Updates since v0.10.3

• Kotlin 1.1.4-3 (#414). Bringing performance improvements and more.

• Better support for Groovy-heavy DSLs (#142, #47, #259). With the introduction of the withGroovyBuilder and withConvention utility extensions. withGroovyBuilder provides a dynamic dispatching DSL with Groovy semantics for better integration with plugins that rely on Groovy builders such as the core maven plugin.

  It supports Groovy keyword arguments and arbitrary nesting, for instance, the following Groovy code,

  repository(url: "scp://repos.mycompany.com/releases") {
    authentication(userName: "me", password: "myPassword")
  }

  can be mechanically translated to the following Kotlin with the aid of withGroovyBuilder to:

  withGroovyBuilder {
    "repository"("url" to "scp://repos.mycompany.com/releases") {
      "authentication"("userName" to "me", "password" to "myPassword")
    }
  }

  Check out the maven plugin configuration sample and the ant usage sample to see these extensions in action.

• Projects using the kotlin-dsl plugin can be edited correctly in IntelliJ (#373). Before this release, lambda expressions passed as org.gradle.api.Action<T> arguments were not being typed accurately and so T member references were highlighted as errors and code completion provided wrong suggestions. These are now working properly except in buildSrc projects.

  

• Seamless testing for projects using the kotlin-dsl plugin (#450). As the gradleKotlinDsl() dependency is now added to the testRuntimeOnly configuration.

• IntelliJ IDEA resolves Gradle script classpath asynchronously (#355). A long awaited feature, IntelliJ no longer blocks the editor while the classpath of the open script is being resolved.

• Maven repository shortcut (#256). Due to popular demand a shortcut has been added to the DSL that simplifies the configuration of maven repositories.

  Instead of writing:

  repositories {
      maven { url = uri("...") }
  }

  Users can now simply write:

  repositories {
      maven(url = "...") // or maven("...")
  }

• Improved Gradle API null safety (#403, #420). An effort is under way to add nullability annotations to the whole Gradle API. Expect more improvements in upcoming releases.

• New samples (#456, #260). A new sample demonstrating how to write a Kotlin DSL friendly Gradle plugin in Groovy has been added as well as another one demonstrating how to configure the (now deprecated) Software Model in Kotlin.

• applyFrom(uri) removed from the DSL (#444). For symmetry, scripts should use apply { from(uri) } instead.

0.10.3

Gradle Kotlin DSL 0.10.3 Release Notes

Gradle Kotlin DSL v0.10.3 is meant to fix a defect in the artifacts published as part of the v0.10.2 release which are otherwise identical.

Please refer to the v0.10.1 and v0.10.2 release notes for details on what's included.

v0.10.3 is expected to be shipped in the upcoming Gradle 4.1.

0.10.2

Gradle Kotlin DSL 0.10.2 Release Notes

Gradle Kotlin DSL v0.10.2 is a minor update to v0.10.1 including a fix to an issue surfaced by the integration into the Gradle 4.1 release branch.

v0.10.2 is expected to be included in the upcoming Gradle 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.1-20170712173431+0000-all.zip

Updates since v0.10.1

• Accessors for extensions with types not available to the build script (#416). It is possible to register project extensions using types that won't necessarily be available on every project's build script compilation classpath. This is the case for plugins injected via init scripts, for example. In v0.10.1, the interaction of such extensions with the automatic generation of Kotlin code that enables statically typed access to project extension would cause build failures due to the unresolved type references. In v0.10.2, accessors for extensions with inaccessible types will carry documentation clearly stating so and have their types erased so they can be compiled successfully.

0.10.1

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
        }
    }

0.9.1

Gradle Script Kotlin 0.9.1 Release Notes

Gradle Script Kotlin v0.9.1 is a patch release meant to unblock the evolution of the internal Gradle API.

See the v0.9.0 release notes for details on what's included.

Updates since v0.9.0

• Migrate to new internal PluginServiceRegistry API (#367).

0.9.0

Gradle Script Kotlin 0.9.0 Release Notes

Gradle Script Kotlin v0.9.0 is another major step forward in usability, bringing improvements to the DSL, IntelliJ experience, performance, and finally automatic detection of Kotlin based builds.

v0.9.0 is expected to be included in the upcoming Gradle 4.0 RC1.

The features in this release are also available for immediate use within the latest Gradle Script Kotlin 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-script-kotlin-4.0-20170518042627+0000-all.zip

Updates since v0.8.0

• Automatic detection of Kotlin based builds (#37, #80). After a little more than an year since the issue was first added to our board this huge usability improvement has finally landed!

  No more rootProject.buildFileName = 'build.gradle.kts' boilerplate or settings.gradle file required in order to enable Kotlin build script! 🎉

• Default imports for the whole Gradle API (#215, #347). To make build scripts more concise, the set of default imports now includes the whole Gradle API as documented in the Default imports section of the Gradle User Guide.

• Improved Gradle API with type safe setters (#341). Kotlin recognizes mutable JavaBean properties only when both the getter and at least one setter agree on the property type.

  More than 50 strongly typed setters have been recently added to the Gradle API enabling build scripts to migrate from invocation heavy configuration syntax such as:

  val someBuild by tasks.creating(GradleBuild::class) {
      setDir(file("some/path"))      // NOT RECOGNIZED AS PROPERTY BECAUSE OF UNTYPED SETTER
      setTasks(listOf("foo", "bar")) // NOT RECOGNIZED AS PROPERTY BECAUSE OF UNTYPED SETTER 
  }

  to the more declarative:

  val someBuild by tasks.creating(GradleBuild::class) {
      dir = file("some/path")
      tasks = listOf("foo", "bar")
  }

• Improved project extension accessors with properties (#330). So one can now write java.sourceSets instead of java().sourceSets as in 0.8.0.

• API documentation (#209). A first cut of this important piece of documentation, generated using Dokka, is now available at https://gradle.github.io/gradle-script-kotlin-docs/api/.

• IntelliJ improvements

  • Classpath computation is now asynchronous (#249). And should no longer block the UI (pending a fix to this IntelliJ issue)

  • Type-safe accessors are correctly included in the classpath given to IntelliJ (#340). Upon changes to the plugins block (pending a fix to this IntelliJ issue)

  • Source code navigation now works for everything Gradle (#281).

    

  • Source code navigation to sources of included Kotlin libraries (#96). As long as there's at least one buildscript repository configured that can resolve the Kotlin source artifacts.

• Miscellaneous

  • Polished Android Sample (#351). With all the improvements in this release, our hello-android sample is now boilerplate free:

    buildscript {
        dependencies {
            classpath("com.android.tools.build:gradle:2.3.1")
            classpath(kotlinModule("gradle-plugin"))
        }
        repositories {
            jcenter()
        }
    }
    
    apply {
        plugin("com.android.application")
        plugin("kotlin-android")
    }
    
    android {
        buildToolsVersion("25.0.0")
        compileSdkVersion(23)
    
        defaultConfig {
            minSdkVersion(15)
            targetSdkVersion(23)
    
            applicationId = "com.example.kotlingradle"
            versionCode = 1
            versionName = "1.0"
        }
    
        buildTypes {
            getByName("release") {
                isMinifyEnabled = false
                proguardFiles("proguard-rules.pro")
            }
        }
    }
    
    dependencies {
        compile("com.android.support:appcompat-v7:23.4.0")
        compile("com.android.support.constraint:constraint-layout:1.0.0-alpha8")
        compile(kotlinModule("stdlib"))
    }
    
    repositories {
        jcenter()
    }

    And it works with the latest Android Studio (2.3.2).

  • Gradle initialization overhead removed (#320). The implementation of type-safe accessors in 0.8.0 added some undue overhead to project configuration even when there was no Kotlin build script involved. This has been fixed.

  • Idiomatic support for Gradle's PropertyState<T> and ConfigurableFileCollection properties (#344). Via Kotlin delegated properties:

    open class GreetingPluginExtension(project: Project) {
    
        // Declare a `PropertyState<String>` backing field
        private
        val messageState = project.property<String>()
    
        // Expose `messageState` as the `message` property whose type is inferred as String
        var message by messageState
    
        // Can also be exposed as `Provider<String>` for additional functionality
        val messageProvider: Provider<String> get() = messageState
    
        // `outputFiles` property type is inferred as `ConfigurableFileCollection`
        // with the following behaviour:
        //  - getting will always return the original instance
        //  - setting will `setFrom` the source
        var outputFiles by project.files()
    }

    Check out the provider-properties sample for more information.

  • Better caching behaviour for type-safe accessors (#338).

• Bug fixes

  • Setting non-existent Kotlin build script in settings.gradle no longer causes the build to fail (#302, #331). Following standard Gradle behaviour.

  • Generated extension accessor for the publishing extension will work as expected (#327, #328). And defer configuration until necessary.

  • Projects with Kotlin build scripts in buildSrc can be edited with the correct classpath in IntelliJ (#339). As build scripts will now be executed in a best-effort manner when computing the classpath.