@eskatos eskatos released this Dec 13, 2018

Assets 2

Gradle Kotlin DSL 1.1.0 Release Notes

Gradle Kotlin DSL 1.1.0 brings Kotlin 1.3.11, support for Kotlin lambdas in the Gradle APIs, multiple fixes and enhancements for a better behavior in IntelliJ script dependency resolution, bug fixes in the kotlin-dsl plugin for build authors, selected type-safe accessors additions and better build-cache support.

In order to benefit from the best user experience, please update IntelliJ IDEA to 2018.3.1, Android Studio to 3.3 and their Kotlin Plugin to the latest 1.3.

v1.1.0 is included in Gradle 5.1-rc-1.

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

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

Updates since v1.0.4 (Gradle 5.0)

  • Kotlin 1.3.11 (#1285)

    Please see the Kotlin 1.3.11 release notes for more information.

  • Gradle APIs now accept Kotlin lambdas (#1077)

    Gradle API members accepting Any and unpacking Groovy closures and Callables lazily now also accept Kotlin lambdas. Instead of

    file(Callable { "foo" })
    files(Callable { "bar" })
    copy {
        from(Callable { "compute/inputs/lazily" })
        // ...
    }

    it is now possible to write:

    file({ "foo" })
    files({ "bar" })
    copy {
        from({ "compute/inputs/lazily" })
        // ...
    }
  • Type-safe accessors for configurations in artifacts {} (#889, #1020, #1276)

    The artifacts {} block now has type-safe accessors to add artifacts to existing configurations. Instead of

    artifacts {
        add("archives", tasks.jar)
    }

    it is now possible to write:

    artifacts {
        archives(tasks.jar)
    }
  • Type-safe accessors for extensions in dependencies {} (#1185, #1190, #1278)

    The dependencies {} block now has type-safe accessors to existing extensions. For example, given an existing extension on the DependencyHandler named acme and providing dependencies declarations one could now write:

    dependencies {
        implementation(acme.core)
    }
  • Script compilation and kotlin-dsl plugin tasks cached outputs can now be shared (#1286, #1288)

    All the generated code is now reproducible byte to byte allowing the Gradle Build Cache support to share the cached outputs between different operating systems.

  • kotlin-dsl plugin tasks are now all cacheable (#1243, #1275)

    The :generateScriptPluginAdapters task contributed by the kotlin-dsl plugin is now cacheable, relocatable and its outputs can be shared between different operating systems.

  • kotlin-dsl plugin now sets Kotlin apiVersion and languageVersion to 1.3 (#1274, #1277)

    For uniformity with script compilation.

  • IDE editor script dependencies is now correct for scripts outside the project root (#1231, #1289)

    Prior to this release, when the layout of a build included subprojects stored outside the build root directory, the script dependencies resolver wouldn't consider those subprojects to be part of the imported project. Instead, the subprojects would be treated as standalone projects most likely causing the wrong classpath to be served to the IDE.

    For example, in the following Gradle build layout where root is the actual Gradle root project directory imported into IntelliJ IDEA and p1 is a subproject outside the root directory tree:

    ├── root
    │   ├── build.gradle.kts
    │   ├── buildSrc
    │   │   └── build.gradle.kts
    │   └── settings.gradle.kts 
    └── p1
        └── build.gradle.kts
    

    With the old and incorrect behaviour, IntelliJ IDEA would receive the wrong classpath for the p1/build.gradle.kts script which was treated as a script plugin with no connection to the p1 subproject.

    This behaviour has been fixed and now scripts for subprojects stored outside the imported project root directory will be correctly recognised as such.

  • IDE editor script dependencies resolution consumes less resources (#1155)

    When editing a .gradle.kts script in IntelliJ IDEA, resolving the script classpath for the first time can take a relatively long time due to the downloading of dependencies and their sources (including the Gradle sources if using a -bin distribution).

    Making changes to a script while a resolution request is pending causes further requests to be enqueued for later processing.

    Prior to this release, the Kotlin DSL would simply serve all pending requests one by one which could end up consuming a lot of resources unnecessarily considering that repeated requests for the uptodate classpath of the same script only needs to be resolved once.

    Starting with this release, the Kotlin DSL script dependencies resolver will only process the most recent request for each script avoiding a lot of unnecessary work.

  • IDE editor script dependencies resolution now better manage its logs (#1267, #1273, #1280, #1281)

    On Windows, the log directory moved from $HOME/Application Data/gradle-kotlin-dsl/log to the more idiomatic and always local $HOME/AppData/Local/gradle-kotlin-dsl/log.

    On all systems, the log directory is now checked periodically (at most every 24 hours) and log files are deleted if they are more than 7 days old.

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

@bamboo bamboo released this Nov 20, 2018

Assets 2

Gradle Kotlin DSL 1.0 Release Notes

Gradle Kotlin DSL 1.0 brings Kotlin 1.3.10, performance improvements, script compilation build cache, API/DSL refinements and fixes.

In order to benefit from the best user experience, please update IntelliJ IDEA to 2018.3, Android Studio to 3.2 and their Kotlin Plugin to the latest 1.3.

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.

The Gradle Plugin Portal now displays Kotlin DSL snippets for easy copy and paste.

This release contains potential breaking changes, see below.

v1.0.4 is included in Gradle 5.0.

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

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

Updates since v1.0.3 (Gradle 5.0 RC3)

  • Kotlin 1.3.10 (#1248)

    Please see the Kotlin 1.3.10 release notes for more information.

  • Reduce code generation overhead (#1202)

    Starting with this release, at most a single IO thread will be used during the code generation phase of script compilation.

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

Updates since v1.0.2 (Gradle 5.0 RC2)

  • Let getting property delegate use getByName() instead of named() (#1247)

  • Let creating property delegate use create() instead of register() (#1246)

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

Updates since v1.0-RC14 (Gradle 5.0 RC1)

  • Let generated source code import default package types (#1205, #1239)

  • The kotlin-dsl plugin don't pin kotlin dependencies anymore (#1241)

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

Updates since v1.0-RC12 (Gradle 5.0 M1)

  • Upgrade embedded Kotlin to 1.3.0 (#1197)

    Please see the Kotlin 1.3 announcement, What’s New page, ChangeLog and Compatibility Guide for more information.

  • Faster script compilation (#1168, #817, #1199)

    The biggest bottleneck in the Gradle Kotlin DSL was the compilation of the generated Kotlin type-safe accessors during script compilation. The most impacted use cases were first time use of a build, and, the feedback loop when making changes to the build logic, both from the command line or in the script editor.

    In this release we replaced the usage of the Kotlin compiler for this particular step by generating the bytecode directly instead. The generated accessors are lean and repetitive, no need for a full-blown compiler to produce their bytecode.

    The IDE experience is preserved, you can still display accessors documentation in context and navigate to their sources.

    On the gradle/kotlin-dsl build with a dozen projects and a fair amount of custom build logic, the feedback loop on API change in buildSrc went from ~10s to ~6s. That's a 40% improvement.

    gradle/kotlin-dsl

    On a small Android application, here the Android Sunflower sample application, the feedback loop on API change in buildSrc went from ~7s down to ~4.5s. That's a 40% improvement too.

    android-sunflower

    The effect is even more drastic on complex builds. On the gradle/gradle build that has almost a hundred projects and a fairly complex build logic, the feedback loop on API change in buildSrc went from ~1 minute down to ~25s. That's a 60% improvement.

    gradle/gradle

    That change has about the same effect on the clean checkout use case, and, improves the first time use of a small build by ~20%. For all use cases, the larger the build, bigger is the impact.

  • Fix Gradle daemon meta space leak caused by kotlin-dsl plugin (#1188)

    A permanent generation / meta space memory leak was introduced in 1.0 RC1 causing the Gradle daemon to consume spurious memory and eventually fail with OutOfMemoryError. This is now fixed. See the linked issue for the tasty details.

  • IDE script resolver skip buildSrc verification tasks (#1174)

    In order to shorten the feedback loop in the .gradle.kts editor, the script dependencies resolver now skips all verification tasks from the buildSrc build if present.

  • Generate compilable container elements accessors for element with type in the default package (#1158, #1162, #1164)

    Previous release introduced type-safe accessors for elements of containers (e.g. tasks.compileJava { }) but they were not compilable and caused builds to fail when the element type was from the default package. This is now fixed.

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

Updates since v1.0-RC6 (Gradle 4.10.2)

  • 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

    Kotlin DSL 1.0 ships with Kotlin 1.3.0.
    Please see the Kotlin 1.3 announcement, What’s New page, ChangeLog and Compatibility Guide for more information.

  • Artifact configuration accessors are now typed NamedDomainObjectProvider<Configuration>

    Instead of simply Configuration. This goes in line with the fact that the Kotlin DSL sugar embraces the new configuration avoidance APIs.
    It will cause compilation errors. The simplest way to fix compilation errors is to add an invocation to .get() to the offending code.

  • Legacy support for project schema JSON snapshot is removed (#1195)

    The legacy support for generating type-safe accessors from a JSON snapshot of the project schema and its companion task :kotlinDslAccessorsSnapshot have been removed.

    If your build logic was relying on accessors generated from gradle/project-schema.json this change might cause build script compilation errors. Those usages need to be replaced with explicit configuration as shown in the What to do when type-safe model accessors are not available? section of the Kotlin DSL documentation.

    In any case, if your build contains a gradle/project-schema.json file you can safely delete it, it is no longer used.

  • Rename PluginAware.apply<T>(to) to PluginAware.applyTo<T>(target) (#1161, #1184)

    The PluginAware.apply<T>(to) extension function was causing ambiguities with PluginAware.apply(plugin = "some.id") and surprising behavior.

    This release renames that extension function to PluginAware.applyTo<T>(target) removing the ambiguity. If you were using that extension then use the new name instead.

  • The kotlin-dsl plugin don't pin kotlin dependencies anymore (#1241)

    This was hiding version conflicts when using failOnVersionConflict() and causing confusion when mixing Kotlin versions. As a result, your build might now fail with version conflicts if you are using failOnVersionConflict().

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.

@eskatos eskatos released this Nov 14, 2018

Assets 2

Gradle Kotlin DSL 1.0 Release Notes

Gradle Kotlin DSL 1.0 brings Kotlin 1.3.0, performance improvements, script compilation build cache, API/DSL refinements and fixes.

In order to benefit from the best user experience, please update IntelliJ IDEA to 2018.3, Android Studio to 3.2 and their Kotlin Plugin to the latest 1.3.

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.

The Gradle Plugin Portal now displays Kotlin DSL snippets for easy copy and paste.

This release contains potential breaking changes, see below.

v1.0.3 is included in Gradle 5.0 RC3.

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

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

Updates since v1.0.2 (Gradle 5.0 RC2)

  • Let getting property delegate use getByName() instead of named() (#1247)

  • Let creating property delegate use create() instead of register() (#1246)

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

Updates since v1.0-RC14 (Gradle 5.0 RC1)

  • Let generated source code import default package types (#1205, #1239)

  • The kotlin-dsl plugin don't pin kotlin dependencies anymore (#1241)

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

Updates since v1.0-RC12 (Gradle 5.0 M1)

  • Upgrade embedded Kotlin to 1.3.0 (#1197)

    Please see the Kotlin 1.3 announcement, What’s New page, ChangeLog and Compatibility Guide for more information.

  • Faster script compilation (#1168, #817, #1199)

    The biggest bottleneck in the Gradle Kotlin DSL was the compilation of the generated Kotlin type-safe accessors during script compilation. The most impacted use cases were first time use of a build, and, the feedback loop when making changes to the build logic, both from the command line or in the script editor.

    In this release we replaced the usage of the Kotlin compiler for this particular step by generating the bytecode directly instead. The generated accessors are lean and repetitive, no need for a full-blown compiler to produce their bytecode.

    The IDE experience is preserved, you can still display accessors documentation in context and navigate to their sources.

    On the gradle/kotlin-dsl build with a dozen projects and a fair amount of custom build logic, the feedback loop on API change in buildSrc went from ~10s to ~6s. That's a 40% improvement.

    gradle/kotlin-dsl

    On a small Android application, here the Android Sunflower sample application, the feedback loop on API change in buildSrc went from ~7s down to ~4.5s. That's a 40% improvement too.

    android-sunflower

    The effect is even more drastic on complex builds. On the gradle/gradle build that has almost a hundred projects and a fairly complex build logic, the feedback loop on API change in buildSrc went from ~1 minute down to ~25s. That's a 60% improvement.

    gradle/gradle

    That change has about the same effect on the clean checkout use case, and, improves the first time use of a small build by ~20%. For all use cases, the larger the build, bigger is the impact.

  • Fix Gradle daemon meta space leak caused by kotlin-dsl plugin (#1188)

    A permanent generation / meta space memory leak was introduced in 1.0 RC1 causing the Gradle daemon to consume spurious memory and eventually fail with OutOfMemoryError. This is now fixed. See the linked issue for the tasty details.

  • IDE script resolver skip buildSrc verification tasks (#1174)

    In order to shorten the feedback loop in the .gradle.kts editor, the script dependencies resolver now skips all verification tasks from the buildSrc build if present.

  • Generate compilable container elements accessors for element with type in the default package (#1158, #1162, #1164)

    Previous release introduced type-safe accessors for elements of containers (e.g. tasks.compileJava { }) but they were not compilable and caused builds to fail when the element type was from the default package. This is now fixed.

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

Updates since v1.0-RC6 (Gradle 4.10.2)

  • 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

    Kotlin DSL 1.0 ships with Kotlin 1.3.0.
    Please see the Kotlin 1.3 announcement, What’s New page, ChangeLog and Compatibility Guide for more information.

  • Artifact configuration accessors are now typed NamedDomainObjectProvider<Configuration>

    Instead of simply Configuration. This goes in line with the fact that the Kotlin DSL sugar embraces the new configuration avoidance APIs.
    It will cause compilation errors. The simplest way to fix compilation errors is to add an invocation to .get() to the offending code.

  • Legacy support for project schema JSON snapshot is removed (#1195)

    The legacy support for generating type-safe accessors from a JSON snapshot of multi-project schema and its companion task :kotlinDslAccessorsSnapshot have been removed. If your build contains a gradle/project-schema.json file you can safely delete it, it is no longer needed.

  • Rename PluginAware.apply<T>(to) to PluginAware.applyTo<T>(target) (#1161, #1184)

    The PluginAware.apply<T>(to) extension function was causing ambiguities with PluginAware.apply(plugin = "some.id") and surprising behavior.

    This release renames that extension function to PluginAware.applyTo<T>(target) removing the ambiguity. If you were using that extension then use the new name instead.

  • The kotlin-dsl plugin don't pin kotlin dependencies anymore (#1241)

    This was hiding version conflicts when using failOnVersionConflict() and causing confusion when mixing Kotlin versions. As a result, your build might now fail with version conflicts if you are using failOnVersionConflict().

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.

@eskatos eskatos released this Nov 12, 2018

Assets 2

Gradle Kotlin DSL 1.0 Release Notes

Gradle Kotlin DSL 1.0 brings Kotlin 1.3.0, performance improvements, script compilation build cache, API/DSL refinements and fixes.

In order to benefit from the best user experience, please update IntelliJ IDEA to 2018.3, Android Studio to 3.2 and their Kotlin Plugin to the latest 1.3.

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.

The Gradle Plugin Portal now displays Kotlin DSL snippets for easy copy and paste.

This release contains potential breaking changes, see below.

v1.0.2 is included in Gradle 5.0 RC2.

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

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

Updates since v1.0-RC14 (Gradle 5.0 RC1)

  • Let generated source code import default package types (#1205, #1239)

  • The kotlin-dsl plugin don't pin kotlin dependencies anymore (#1241)

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

Updates since v1.0-RC12 (Gradle 5.0 M1)

  • Upgrade embedded Kotlin to 1.3.0 (#1197)

    Please see the Kotlin 1.3 announcement, What’s New page, ChangeLog and Compatibility Guide for more information.

  • Faster script compilation (#1168, #817, #1199)

    The biggest bottleneck in the Gradle Kotlin DSL was the compilation of the generated Kotlin type-safe accessors during script compilation. The most impacted use cases were first time use of a build, and, the feedback loop when making changes to the build logic, both from the command line or in the script editor.

    In this release we replaced the usage of the Kotlin compiler for this particular step by generating the bytecode directly instead. The generated accessors are lean and repetitive, no need for a full-blown compiler to produce their bytecode.

    The IDE experience is preserved, you can still display accessors documentation in context and navigate to their sources.

    On the gradle/kotlin-dsl build with a dozen projects and a fair amount of custom build logic, the feedback loop on API change in buildSrc went from ~10s to ~6s. That's a 40% improvement.

    gradle/kotlin-dsl

    On a small Android application, here the Android Sunflower sample application, the feedback loop on API change in buildSrc went from ~7s down to ~4.5s. That's a 40% improvement too.

    android-sunflower

    The effect is even more drastic on complex builds. On the gradle/gradle build that has almost a hundred projects and a fairly complex build logic, the feedback loop on API change in buildSrc went from ~1 minute down to ~25s. That's a 60% improvement.

    gradle/gradle

    That change has about the same effect on the clean checkout use case, and, improves the first time use of a small build by ~20%. For all use cases, the larger the build, bigger is the impact.

  • Fix Gradle daemon meta space leak caused by kotlin-dsl plugin (#1188)

    A permanent generation / meta space memory leak was introduced in 1.0 RC1 causing the Gradle daemon to consume spurious memory and eventually fail with OutOfMemoryError. This is now fixed. See the linked issue for the tasty details.

  • IDE script resolver skip buildSrc verification tasks (#1174)

    In order to shorten the feedback loop in the .gradle.kts editor, the script dependencies resolver now skips all verification tasks from the buildSrc build if present.

  • Generate compilable container elements accessors for element with type in the default package (#1158, #1162, #1164)

    Previous release introduced type-safe accessors for elements of containers (e.g. tasks.compileJava { }) but they were not compilable and caused builds to fail when the element type was from the default package. This is now fixed.

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

Updates since v1.0-RC6 (Gradle 4.10.2)

  • 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

    Kotlin DSL 1.0 ships with Kotlin 1.3.0.
    Please see the Kotlin 1.3 announcement, What’s New page, ChangeLog and Compatibility Guide for more information.

  • Artifact configuration accessors are now typed NamedDomainObjectProvider<Configuration>

    Instead of simply Configuration. This goes in line with the fact that the Kotlin DSL sugar embraces the new configuration avoidance APIs.
    It will cause compilation errors. The simplest way to fix compilation errors is to add an invocation to .get() to the offending code.

  • Legacy support for project schema JSON snapshot is removed (#1195)

    The legacy support for generating type-safe accessors from a JSON snapshot of multi-project schema and its companion task :kotlinDslAccessorsSnapshot have been removed. If your build contains a gradle/project-schema.json file you can safely delete it, it is no longer needed.

  • Rename PluginAware.apply<T>(to) to PluginAware.applyTo<T>(target) (#1161, #1184)

    The PluginAware.apply<T>(to) extension function was causing ambiguities with PluginAware.apply(plugin = "some.id") and surprising behavior.

    This release renames that extension function to PluginAware.applyTo<T>(target) removing the ambiguity. If you were using that extension then use the new name instead.

  • The kotlin-dsl plugin don't pin kotlin dependencies anymore (#1241)

    This was hiding version conflicts when using failOnVersionConflict() and causing confusion when mixing Kotlin versions. As a result, your build might now fail with version conflicts if you are using failOnVersionConflict().

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 Oct 30, 2018

Assets 2

Gradle Kotlin DSL 1.0 RC14 Release Notes

Gradle Kotlin DSL 1.0 RC14 brings Kotlin 1.3.0, performance improvements, script compilation build cache, API/DSL refinements and fixes.

In order to benefit from the best user experience, please update IntelliJ IDEA to 2018.3, Android Studio to 3.2 and their Kotlin Plugin to the latest 1.3.

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.

The Gradle Plugin Portal now displays Kotlin DSL snippets for easy copy and paste.

This release contains potential breaking changes, see below.

v1.0-RC14 is included in Gradle 5.0 RC1.

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

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

Updates since v1.0-RC12

  • Upgrade embedded Kotlin to 1.3.0 (#1197)

    Please see the Kotlin 1.3 announcement, What’s New page, ChangeLog and Compatibility Guide for more information.

  • Faster script compilation (#1168, #817, #1199)

    The biggest bottleneck in the Gradle Kotlin DSL was the compilation of the generated Kotlin type-safe accessors during script compilation. The most impacted use cases were first time use of a build, and, the feedback loop when making changes to the build logic, both from the command line or in the script editor.

    In this release we replaced the usage of the Kotlin compiler for this particular step by generating the bytecode directly instead. The generated accessors are lean and repetitive, no need for a full-blown compiler to produce their bytecode.

    The IDE experience is preserved, you can still display accessors documentation in context and navigate to their sources.

    On the gradle/kotlin-dsl build with a dozen projects and a fair amount of custom build logic, the feedback loop on API change in buildSrc went from ~10s to ~6s. That's a 40% improvement.

    gradle/kotlin-dsl

    On a small Android application, here the Android Sunflower sample application, the feedback loop on API change in buildSrc went from ~7s down to ~4.5s. That's a 40% improvement too.

    android-sunflower

    The effect is even more drastic on complex builds. On the gradle/gradle build that has almost a hundred projects and a fairly complex build logic, the feedback loop on API change in buildSrc went from ~1 minute down to ~25s. That's a 60% improvement.

    gradle/gradle

    That change has about the same effect on the clean checkout use case, and, improves the first time use of a small build by ~20%. For all use cases, the larger the build, bigger is the impact.

  • Fix Gradle daemon meta space leak caused by kotlin-dsl plugin (#1188)

    A permanent generation / meta space memory leak was introduced in 1.0 RC1 causing the Gradle daemon to consume spurious memory and eventually fail with OutOfMemoryError. This is now fixed. See the linked issue for the tasty details.

  • IDE script resolver skip buildSrc verification tasks (#1174)

    In order to shorten the feedback loop in the .gradle.kts editor, the script dependencies resolver now skips all verification tasks from the buildSrc build if present.

  • Generate compilable container elements accessors for element with type in the default package (#1158, #1162, #1164)

    Previous release introduced type-safe accessors for elements of containers (e.g. tasks.compileJava { }) but they were not compilable and caused builds to fail when the element type was from the default package. This is now fixed.

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

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

    Kotlin DSL 1.0-rc-14 ships with Kotlin 1.3.0.
    Please see the Kotlin 1.3 announcement, What’s New page, ChangeLog and Compatibility Guide for more information.

  • Artifact configuration accessors are now typed NamedDomainObjectProvider<Configuration>

    Instead of simply Configuration. This goes in line with the fact that the Kotlin DSL sugar embraces the new configuration avoidance APIs.
    It will cause compilation errors. The simplest way to fix compilation errors is to add an invocation to .get() to the offending code.

  • Legacy support for project schema JSON snapshot is removed (#1195)

    The legacy support for generating type-safe accessors from a JSON snapshot of multi-project schema and its companion task :kotlinDslAccessorsSnapshot have been removed. If your build contains a gradle/project-schema.json file you can safely delete it, it is no longer needed.

  • Rename PluginAware.apply<T>(to) to PluginAware.applyTo<T>(target) (#1161, #1184)

    The PluginAware.apply<T>(to) extension function was causing ambiguities with PluginAware.apply(plugin = "some.id") and surprising behavior.

    This release renames that extension function to PluginAware.applyTo<T>(target) removing the ambiguity. If you were using that extension then use the new name instead.

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 Oct 3, 2018 · 386 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

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.