groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: Binary compatibility fixed + Kotlin DSL
Date Thu, 21 Mar 2019 06:44:46 GMT
There seems to be enough desire to keep the files as Groovy, so I'll revert
for the time being. We can look at this issue again a bit further down the
track and see if there is a greater level of comfort in switching.

Cheers, Paul.

On Thu, Mar 21, 2019 at 12:03 PM MG <> wrote:

> Hi Cédric,
> I think that It should be obvious that there is a conflict of interests
> here, and that agreeing to you suggestion looks to be worse for Groovy than
> the very old saying by the original Groovy author about "never having done
> Groovy if he had known a certain other language existed" (all taken back
> later and no longer relevant - but still quoted in discussions many years
> later).
> 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 (having worked with purely dynamic Groovy for years using IntelliJ
> IDEA, I also have at least some doubts about the whole "you cannot supply
> good Intellisense for Gradle DSL" mantra), also in Gradle.
> Instead they decided to develop their own independent language, evidently
> very much inspired by Groovy, with imho some doubtful syntax & design
> decisions where it deviates (and of course missing the dynamic support and
> powerful annotations, as well as the big Groovy ecosystem). Having
> Jetbrains behind it and evidently being heavily invested in it, is not just
> another language on the block that joins the happy family of Java
> alternatives. Jetbrains is pushing their language aggressively (including
> but not restricted to on Wikipedia), and they have already scored at least
> twice: One with the deal with Google Android development, and second with
> Gradle adapting Kotlin as an alternative base for its DSL.
> The same as Jetbrains must want to get rid of supporting a complex
> language like Groovy and replacing it with their own language if possible
> for purely economical reasons (Note that some Groovy 2.5 features are still
> not supported in IntelliJ, months after release), Gradle Inc. must want to
> only support a single DSL code base. Evidently this is the Kotlin based
> one, otherwise why introduce it in the first place ? The problem is that it
> seems uptake of the new DSL has been slow, as people see no (or not enough)
> reason to switch from Groovy. So of course there are no current plans to
> scrap Groovy support in Gradle, since that would be suicide. You can try to
> convince me otherwisem but it would be very surprising to me, if that would
> not change, should a certain percentage of users shift.
> I can't say how hard this would be on a technical level, and while it is
> unlikely, it could potentially still be nice if Groovy and Kotlin would
> join forces, with the static part of Groovy being merged with Kotlin, just
> with nice groovy Java/Groovy syntax, and without the uselessly restrictive
> things in Kotlin (that way people could actually choose what language
> variety to use). Then this whole discussion would dissapear, but since, as
> I said Jetbrains already decided against that option, and instead invested
> several years into developing their own language from scratch...*.
> Just my 50 Cents (from "Get Groovy or Die Trying"),
> mg
> *Others here of course have much more insight than me into these matters,
> including you (but see under conflict of interests).
> On 20/03/2019 22:41, Cédric Champeau wrote:
> Well I think I disagree with most of what you just said. And Gradle Inc
> will not deprecate the groovy support anytime soon. I'm well placed to know
> it's not even in discussion. The only thing that I see could lead to such a
> decision would be that groovy doesn't run on future versions of the JVM.
> Let's not take decisions on speculations, but facts.
> Le mer. 20 mars 2019 à 22:35, Sergio del Amo Caballero <
>> a écrit :
>> I don’t know what do you imply that I am trying to hide.
>> I think:
>> - Gradle Groovy DSL helps Groovy adoption and thus survival.
>> same as Geb DSL on top of Selenium helps Groovy adoption and thus
>> survival.
>> I think if everyone moves to Kotlin DSL, Gradle Inc will lose interest in
>> maintaining Groovy Gradle DSL and eventually deprecate the Groovy Gradle
>> DSL and remove it and hurt Groovy adoption and thus survival .
>> I think that Apache Groovy build transitions towards Kotlin DSL is a
>> signal towards prompting that move.
>>  About maintaining the build itself:
>> - If the only person touching the build is going to be someone with
>> Kotlin and Groovy knowledge, then I would say better to have the DSL in the
>> language they are more productive with it.
>> - If persons, who touch the build, don’t know Kotlin, I think that it is
>> another barrier. I assume that someone with no Kotlin Knowledge but using
>> the Kotlin DSL and assisted by the IDE support is going to do a worst job
>> than someone with a lot of Groovy knowledge using the Groovy Gradle DSL.
>> Sergio del Amo
>> On 20 Mar 2019, at 21:50, Cédric Champeau <>
>> wrote:
>> And do you honestly think that trying to hide that by not using the
>> Kotlin DSL would change anything?
>> Le mer. 20 mars 2019 à 21:45, Sergio Del Amo <>
>> a écrit :
>>> I do in fact see this as at least a minor threat.  If Groovy itself
>>> can't even manage to use the Gradle Groovy DSL, what hope remains for the
>>> survival of the Groovy DSL?
>>> Agree. I see a threat at least to Gradle Groovy DSL survival and
>>> probably to Groovy in general. One may reason: If the Groovy programming
>>> language build, which is manipulated by the people with more Groovy
>>> knowledge in the planet, moved to Kotlin DSL, why should anyone else keep
>>> using the Gradle Groovy DSL.
>>> Sergio
>>> On 20 Mar 2019, at 16:00, Milles, Eric (TR Tech, Content & Ops) <
>>>> wrote:
>>> I tried to get some info from Gradle on adding Eclipse DSLD for Gradle
>>> and they scoffed at me.  They said it was a multi-person, multi-year effort
>>> so why even try.  I was able to get some very basic support without
>>> that much effort.  It could be moved forward and probably ported to
>>> IntelliJ as well if there was some interest and support.
>>> With regards to the change to the Groovy build script.  I'm not sure
>>> newcomers are diving into the build scripts and making edits there.
>>> My intuition is that they are running "./gradlew build" or whatever the
>>> command is.  As long as the scripts run successfully, I'd posit a newcomer
>>> is quite happy.
>>> I do in fact see this as at least a minor threat.  If Groovy itself
>>> can't even manage to use the Gradle Groovy DSL, what hope remains for the
>>> survival of the Groovy DSL?

View raw message