We augment the Java Gradle API with generated Kotlin extensions. The source of those extensions is generated at runtime, on top of the Gradle API JAR, and compiled using the embedded Kotlin compiler.
Every machine where a Kotlin DSL script is compiled has to do this code generation and compilation and store the output in the Gradle User Home. It is quite costly on first use.
Moving this code generation to Gradle distribution build time will make all first use scenarios faster. This is important for the perceived performance of Gradle and for ephemeral CI agents performance. This should also make our test suite faster given a number of tests use isolated Gradle User Homes.
All users of the Gradle Kotlin DSL will see the first use performance benefit.
Moreover, the Kotlin extensions generated on top of the Java Gradle API are currently not covered by the binary compatibility check. By moving the generation at distribution build time we can easily include them into the binary compatibility check.
We augment the Java Gradle API with generated Kotlin extensions. The source of those extensions is generated at runtime, on top of the Gradle API JAR, and compiled using the embedded Kotlin compiler.
Every machine where a Kotlin DSL script is compiled has to do this code generation and compilation and store the output in the Gradle User Home. It is quite costly on first use.
Moving this code generation to Gradle distribution build time will make all first use scenarios faster. This is important for the perceived performance of Gradle and for ephemeral CI agents performance. This should also make our test suite faster given a number of tests use isolated Gradle User Homes.
All users of the Gradle Kotlin DSL will see the first use performance benefit.
Moreover, the Kotlin extensions generated on top of the Java Gradle API are currently not covered by the binary compatibility check. By moving the generation at distribution build time we can easily include them into the binary compatibility check.