On Fri, Mar 22, 2019 at 11:37 AM Thibault Kruse <tibokr...@googlemail.com> wrote: > > While that is obviously true, the question is not as simple. The > groovy community must make a recommendation to all gradle projects in > the world about whether to use Gradle-Groovy-DSL or Gradle-Kotlin-DSL.
Answering myself, after having migrated a project of mine to Kotlin. My experience has been maybe similar to this article: https://proandroiddev.com/takeaways-from-migrating-a-complex-android-project-to-gradle-kotlin-dsl-eaeb5ccd8c84?gi=32fc005af2ba The experience of working with the Kotlin DSL is mixed. It makes a big difference which gradle and which IntelliJ version are used exactly, and in large projects where different people use different versions, and different plugins may require different versions, it is an additional pain to be bound to the latest version of everything (As an example best kotlin support requires gradle5, but the spotbugs plugin seems broken with gradle5). IntelliJ frequently marked half the kotlin files in red for being unable to resolve symbols, though restarting and such helped. Kotlin seems slower than Gradle (also mentioned in the article), and the migration path is not obvious when using 3rdparty plugins or custom code. The documentation about this is still meagre. And on the other hand, IDE support for Gradle-Groovy-DSL can be greatly improved by verbosely explictly using types. E.g. // bad pmd { toolVersion = '6.4.0' } // good import org.gradle.api.plugins.quality.PmdExtension pmd { PmdExtension pmdExt -> pmdExt.toolVersion = '6.4.0' } This may be uglier to write than the idiomatic Gradle, but can be a viable alternative to switching to Kotlin. And Gradle Inc. could promote this kind of syntax for Gradle-Groovy-DSL over the traditional minimal (with obfuscated typing) syntax. Gradle Inc. could also provide more Interfaces to use for such explicit typing, instead of providing static compilation. E.g project.sourceSets.main cannot be resolved in the IDE, but an interface could be provided such that javaProject(project).sourceSets.main would be supported in the IDE. IntelliJ provides full support for writing dynamically compiled Groovy when the types are explicitly provided. I also generally recommend using the buildSrc folder for managing shared build logic and constants (such as for dependencies) in multi-project builds. "apply from: <path/to/other/gradle/file>" on the other hand seems quite confusing, limited and does not scale well with complexity. So for Javaprojects using certain 3rd party (or in-house) plugins, staying with Groovy for the time being may be quite reasonable, also until APIs have matured and IDE and gradle support varies less between versions. For the Groovy project itself I am not sure how much better Kotlin would be than non-idiomatic explicitly typed Groovy-DSL.
