Pre-release
Pre-release

@eskatos eskatos released this Oct 3, 2018 · 68 commits to develop since this release

Assets 2

Gradle Kotlin DSL 1.0 RC12 Release Notes

Gradle Kotlin DSL 1.0 RC12 brings Kotlin 1.3.0 RC2, fixes to issues identified since 1.0 RC6, API/DSL refinements and enables the script compilation build cache.

In order to benefit from the best user experience, please update IntelliJ IDEA to 2018.3 EAP, Android Studio to 3.2 and their Kotlin Plugin to the latest 1.3 EAP (1.3.0-rc-116 at the time of this writing).

Thanks to a great help from the community, the Gradle User Manual now contains samples for both the Groovy and Kotlin DSLs. This is now the best place to find information on how to use the Gradle Kotlin DSL as it covers all Gradle features from using plugins to customizing the dependency resolution behavior.

A new user manual chapter dedicated to the Gradle Kotlin DSL has also been added.

This release contains potential breaking changes, see below.

v1.0-RC12 is included in Gradle 5.0-M1.

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

$ cd $YOUR_PROJECT_ROOT
$ gradle wrapper --gradle-version 5.0-milestone-1 --distribution-type all

Updates since v1.0-RC6

  • Upgrade embedded Kotlin to 1.3.0-RC2 (#1149, #1005, #1112, #1125, #1132)

    Note that Gradle Kotlin DSL 1.0 will ship with Kotlin 1.3 GA.

  • Script compilation build cache is now enabled alongside the Gradle Build Cache (#1152)

    If you enable the Gradle Build Cache then the Gradle Kotlin DSL will store and fetch the outputs of script compilation, avoiding the expensive work of recompiling them.

  • Accessors for plugins present in buildSrc (#1156)

    You can now refer statically to plugins declared in buildSrc. Instead of:

    plugins {
        id("my.buildSrc.plugin.ID")
    }

    you can now write:

    plugins {
        my.buildSrc.plugin.ID
    }
  • Accessors for elements of collections (#879, #1041)

    It is now possible to refer to elements of collections available at build script body compilation time via type-safe accessors. This is applied to configurations, tasks and all Gradle extensions that are collections such as sourceSets. For tasks, it means that instead of writing:

    plugins {
        java
    }
    
    tasks {
        named<Test>("test") {
            testLogging.showStacktraces = true
        }
    }

    you can now write:

    plugins {
        java
    }
    
    tasks {
        test {
            testLogging.showStacktraces = true
        }
    }
  • Accessors for artifact configurations in configurations {} (#1118, #1129)

    Accessors for artifact configurations were missing in the configurations {} block. This has been fixed the same way as for all collections, see above. Instead of:

    plugins {
        java
    }
    
    configurations {
        named("implementation") {
            exclude(group = "org.foo")
        }
    }

    you can now write:

    plugins {
        java
    }
    
    configurations {
        implementation {
            exclude(group = "org.foo")
        }
    }
  • Refine dependency constraints DSL (#710, #1091)

    Accessors for artifact configurations were missing in the dependencies { constraints {} } block. This has been fixed. Instead of:

    plugins {
        java
    }
    
    dependencies {
        constraints {
            add("implementation", "com.google.collections:google-collections") {
                version { rejectAll() }
                because("Google collections is superceded by Guava")
            }
        }
    }

    you can now write:

    plugins {
        java
    }
    
    dependencies {
        constraints {
            implementation("com.google.collections:google-collections") {
                version { rejectAll() }
                because("Google collections is superceded by Guava")
            }
        }
    }
  • Refine containers API (#1042, #1104, #1108, #1116)

    During the RC phase, several discrepancies were found in the domain object collections and containers API. Special care has been taken to iron it in this release. Please see the linked issues for more information.

  • Let the kotlin-dsl plugin configure precompiled script plugins support (#1135)

    Applying the kotlin-dsl plugin now also applies the kotlin-dsl-precompiled-script-plugins plugin. See the Gradle Kotlin DSL Primer chapter of the Gradle User Manual for more information.

  • Refine IDE script dependencies resolver (#1133, #1124, #1139)

    The dependencies resolver backing IDE editors for .gradle.kts scripts has been refined to emit warnings only when necessary and display actionable messages. Please see the linked issues for more information.

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

Breaking changes

This release contains some potential breaking changes:

  • Upgrade embedded Kotlin to 1.3.0-RC2

    Kotlin DSL 1.0-rc-12 ships with Kotlin 1.3 RC2 (1.3.0-rc-116) which is only available via the kotlin-eap repository.
    Usually, that would mean that in order to use the kotlin-dsl plugin or the embedded Kotlin plugin version, the kotlin-eap repository would have to be added to settings.pluginManagement.repositories
    and allprojects.repositories. With the intent of making it easier to try, Kotlin DSL 1.0-rc-12 does it automatically for any project that includes a settings.gradle.kts.
    This behaviour will be removed once Kotlin 1.3 GA is available.

  • Artifact configuration accessors are now typed NamedDomainObjectProvider<Configuration>

    Instead of simply Configuration. This goes in line with the fact that the Kotlin DSL sugar embrace the new configuration avoidance APIs.

Avoiding Gradle Kotlin DSL internal APIs

Use of Kotlin DSL internal APIs in plugins and build scripts has the potential to break builds when either Gradle or plugins change.

The Kotlin DSL extends the Gradle public API definition with org/gradle/kotlin/dsl/* excluding any subpackages.

Pre-release
Pre-release

@eskatos eskatos released this Sep 12, 2018 · 1 commit to bamboo/v1.0-RC6 since this release

Assets 2

Gradle Kotlin DSL 1.0 RC6 Release Notes

Gradle Kotlin DSL 1.0 RC6 brings Kotlin 1.2.61, 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-RC6 is included in Gradle 4.10.1.

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

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

Updates since v1.0-RC3

  • Upgrade embedded Kotlin to 1.2.61 (#1059)

  • Let script templates declare JVM target 1.8 (#1067, #1069)

  • Generate compilable accessors for extension types in the default package (#807,#1060)

  • Regenerate accessors jar upon classpath changes (#1061)

  • Configuring Project fails when non-jar in build script classpath (#1021, #1039)

  • Using the build-scan property extension should apply the same build-scan plugin version as running with --scan (#1083, #1085, gradle/gradle#6713)

  • Apply method in settings script is ambiguous (#1066, #1069)

  • duplicatesStrategy property of Copy task cannot be set in buildSrc (#1070, gradle/gradle#6533)

  • ScriptHandlerScope is missing overloads for adding dependencies (#1048, #1084)

Updates since v1.0-RC1

  • Add missing specialized withType<T>() extensions on NamedDomainObjectCollection (#1034, #1035)

  • Let build-cache be enabled via system property instead of project property (#1032, #1036)

  • Make the build cache keys compatible with the remote build cache (#1023, #1027)

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.

    image

    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.

    intellij-gradle kts-buildsrc-change-auto-reload

    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..:

    image

  • 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 = project.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, 1.0-RC2 and 1.0-RC3.

Breaking changes

This release contains some potential breaking changes:

  • java.sourceSets now is sourceSets
    The source set container can now be accessed using project.sourceSets, or just sourceSets. Previously it was located at project.java.sourceSets, or just java.sourceSets.

  • Container String invoke now is named() instead of maybeCreate()
    This change in behaviour can cause builds to fail with org.gradle.api.UnknownDomainObjectException. The fix is to explicitly call create or preferably register.

    For a concrete example, the following script which, before this change, would cause a new configuration named mine to be created would now fail with Configuration with name 'mine' not found.:

    configurations {
        "mine" { isVisible = false }
    }

    The fix, as explained above, is to introduce an explicit call to create:

    configurations {
        create("mine") { isVisible = false }
    }
  • 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.

  • The kotlin-dsl plugin now requires a repository to be declared
    With Kotlin 1.2.60, the Kotlin Gradle Plugin driving the kotlin compiler requires extra dependencies that aren't required by Gradle Kotlin DSL scripts alone and aren't embedded into Gradle.

    This can be fixed by adding a repository that contains Kotlin compiler dependencies on the project where the kotlin-dsl plugin is applied:

    repositories {
        jcenter()
    }

Avoiding Gradle Kotlin DSL internal APIs

Use of Kotlin DSL internal APIs in plugins and build scripts has the potential to break builds when either Gradle or plugins change.

The Kotlin DSL extends the Gradle public API definition with org/gradle/kotlin/dsl/* excluding any subpackages.

Pre-release
Pre-release

@eskatos eskatos released this Aug 14, 2018

Assets 2

Gradle Kotlin DSL 1.0 RC3 Release Notes

Gradle Kotlin DSL 1.0 RC3 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-RC3 is included in Gradle 4.10 RC3.

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

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

Updates since v1.0-RC1

  • Add missing specialized withType<T>() extensions on NamedDomainObjectCollection (#1034, #1035)

  • Let build-cache be enabled via system property instead of project property (#1032, #1036)

  • Make the build cache keys compatible with the remote build cache (#1023, #1027)

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.

    image

    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.

    intellij-gradle kts-buildsrc-change-auto-reload

    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..:

    image

  • 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 = project.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, 1.0-RC2 and 1.0-RC3.

Breaking changes

This release contains some potential breaking changes:

  • java.sourceSets now is sourceSets
    The source set container can now be accessed using project.sourceSets, or just sourceSets. Previously it was located at project.java.sourceSets, or just java.sourceSets.

  • Container String invoke now is named() instead of maybeCreate()
    This change in behaviour can cause builds to fail with org.gradle.api.UnknownDomainObjectException. The fix is to explicitly call create or preferably register.

    For a concrete example, the following script which, before this change, would cause a new configuration named mine to be created would now fail with Configuration with name 'mine' not found.:

    configurations {
        "mine" { isVisible = false }
    }

    The fix, as explained above, is to introduce an explicit call to create:

    configurations {
        create("mine") { isVisible = false }
    }
  • 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.

  • The kotlin-dsl plugin now requires a repository to be declared
    With Kotlin 1.2.60, the Kotlin Gradle Plugin driving the kotlin compiler requires extra dependencies that aren't required by Gradle Kotlin DSL scripts alone and aren't embedded into Gradle.

    This can be fixed by adding a repository that contains Kotlin compiler dependencies on the project where the kotlin-dsl plugin is applied:

    repositories {
        jcenter()
    }

Avoiding Gradle Kotlin DSL internal APIs

Use of Kotlin DSL internal APIs in plugins and build scripts has the potential to break builds when either Gradle or plugins change.

The Kotlin DSL extends the Gradle public API definition with org/gradle/kotlin/dsl/* excluding any subpackages.

Pre-release
Pre-release

@eskatos eskatos released this Aug 9, 2018

Assets 2

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.

    image

    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.

    intellij-gradle kts-buildsrc-change-auto-reload

    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..:

    image

  • 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.

Pre-release
Pre-release

@eskatos eskatos released this Jul 3, 2018

Assets 2

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.

    image
    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.

    image

  • 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.

Pre-release
Pre-release

@eskatos eskatos released this May 24, 2018

Assets 2

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

Breaking changes

There are no breaking changes upgrading from 0.17.4 to 0.17.5.

Pre-release
Pre-release

@eskatos eskatos released this May 15, 2018

Assets 2

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:

    image

  • 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.

Pre-release
Pre-release

@eskatos eskatos released this Apr 3, 2018

Assets 2

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.

    precompiled-script-plugin-sample

    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.
    
Pre-release
Pre-release

@bamboo bamboo released this Feb 16, 2018 · 1198 commits to master since this release

Assets 2

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:
    image
    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:
    image

  • 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.

Pre-release
Pre-release

@bamboo bamboo released this Jan 4, 2018 · 1350 commits to master since this release

Assets 2

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