groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <tibokr...@googlemail.com>
Subject Re: Binary compatibility fixed + Kotlin DSL
Date Fri, 22 Mar 2019 02:37:35 GMT
On Thu, Mar 21, 2019 at 11:03 AM MG <mgbiz@arscreat.com> wrote:
>
> Maybe I am missing something, but it seems to me that Jetbrains could have put their
weight behind Groovy, especially its static part, gaining all the benefits with regards to
tool support / Intellisense they now claim for Kotlin

I believe in this 2016 article Cedric had explained in good detail why
this is not a mere matter of Jetbrains putting more weight behind
anything:
http://melix.github.io/blog/2016/05/gradle-kotlin.html

On Thu, Mar 21, 2019 at 6:35 AM Sergio del Amo Caballero
<sergio.delamo@softamo.com> wrote:
> - Gradle Groovy DSL helps Groovy adoption and thus survival.
> same as Geb DSL on top of Selenium helps Groovy adoption and thus survival.

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.
And for developers to take the groovy community seriously, this
recommendation should be based on a *technical* argument. Merely
begging: "Please use Groovy for your builds to help Groovy survive" is
not an argument to be taken very seriously.

So far I have only seen the argument that a developer basis already
using Groovy for the production/test sources will benefit from their
Groovy knowledge when maintaining the build files. This can
counter-balance the strength of Gradle-Kotlin-DSL in the area of IDE
support (It's a personal choice).
But if that is the only argument we have for Gradle-Kotlin-DSL over
Gradle-Groovy-DSL, then this implies that any project in the world not
using Groovy for test/production is better off using
Gradle-Kotlin-DSL.

Cedric however took a much stronger position, saying that as an expert
in Groovy and Gradle (and supposedly newcomer to Kotlin), he
recommends Gradle-Kotlin-DSL for the Groovy project. This would imply
that all other gradle projects in the world (including those where the
developers are familiar with Groovy and unfamiliar with Kotlin) should
switch to Gradle-Kotlin-DSL at the earliest convenience.

And so far in this discussion, I have not seen anyone saying that they
tried both, Gradle-Kotlin-DSL and Gradle-Groovy-DSL, and still
preferred Gradle-Groovy-DSL after their investigation. And that's a
very weak stance, supporting a recommendation only out of political
reasons and ignorance of a different technology.

So are there any other arguments to recommend to Gradle projects to
use Gradle-Groovy-DSL over Gradle-Kotlin-DSL? What's the main sales
pitch here?

Mime
View raw message