groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Binary compatibility fixed + Kotlin DSL
Date Tue, 02 Apr 2019 16:56:53 GMT
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
> <tibokruse@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.
>


Mime
View raw message