Hi,
I have never used it, but what you write is within my expectations. We
should not forget we are *still* (after years) talking about an early
version of the DSL.
My experience with other people doing gradle is more like this:
There is a problem, we search on stackoverflow and copy+paste the
solution to see if it works. If it does great, if not, search again.
Most do not try to understand the logic behind. And I can't blame
people, I do similar things when I have to deal with maven builds...
Only that maven does not expose internal logic directly and often you
are lost fast, while gradle would in theory allow you to learn how it
works gradually. Anyway... in cases like that you rarely care about code
completion. These things get interesting once your build is more complex
and you start doing things special. Here the Groovy DSL stays under its
potential, because of reasons you mentioned, because of missing DSLDs
and other things.
All in all things would get more interesting in a version 2 of the
Kotlin DSL, one really tailored to Kotlin, trying to do things better.
Here my expectations would have been that this would have happened
already... I start wondering if it will happen at all.
bye Jochen
On 02.04.19 16:13, Thibault Kruse wrote:
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.
