Samples builds using the Gradle Kotlin DSL
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
Please check out the v0.12.0 release notes for details.
org.gradle.api.provider.PropertyState
are now also available to org.gradle.api.provider.Property
.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
Please check out the v0.12.0 release notes for details.
--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.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
Please check out the v0.12.0 release notes for details.
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.
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
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.
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:
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")
}
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")
}
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
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
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.
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.
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
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
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:
embedded-kotlin
plugin (#392) to ensure Kotlin code gets compiled against the included version of the Kotlin compilergradleKotlinDsl()
thus making the Kotlin DSL extensions available to any Kotlin codeorg.gradle.api.Action<T>
is treated as T.() -> Unit
just like it is in build scriptsCheckout this sample for a demonstration.
IntelliJ improvements
Performance and Stability
Miscellaneous
project-schema.json
file to gradle/project-schema.json
(#398)extra
property initialization (#307)build-scan
plugin (#404)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
}
}
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.
PluginServiceRegistry
API (#367).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
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! :tada:
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.