groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <>
Subject Re: Binary compatibility fixed + Kotlin DSL
Date Tue, 02 Apr 2019 14:13:48 GMT
On Fri, Mar 22, 2019 at 11:37 AM Thibault Kruse
<> 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:

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.


// 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
For the Groovy project itself I am not sure how much better Kotlin
would be than non-idiomatic explicitly typed Groovy-DSL.

View raw message