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 Fri, 22 Mar 2019 04:54:50 GMT
Hi Thibault,

I think the Groovy community has always shown itself to be embracing
of the entire JVM ecosystem and beyond. And for the most part has shown
itself to be very respectful of other community members. I don't think
has changed. The pace of progress has slowed a little and we are more
guarded in what we accept into the project. As a community where all of
us are part-time contributors, we try very hard to minimise changes which
will increase our maintenance burden and we perhaps are a little more
conservative in which changes we accept into the project than we have
been in the past.

I can think of many proposals which have been rejected (or deferred) as
currently not adding enough value for inclusion:

* GProperties
* Tuple "library" for functional programming
* Refined closures syntax with genetics
* Closer alignment of GString and String
* and/or/not aliases for &&, ||, !
* dedicated immutable/persistent collections

Other things which were initially rejected are later accepted (after further
evolution, lobbying and refinement):

* Swapping CliBuilder to support another underlying library
* Elvis assignment
* try-with-resources
* classic for loop

The CliBuilder example is a good case in point. If we were driven by
motives we might have stuck with only supporting Commons CLI which is
another Apache project, but we didn't - we now support both. So we didn't
abandon our existing users yet we have another option supporting what
some would argue is a much better CLI user experience. But it took lobbying,
refinements and evolution before that path was taken.

I haven't heard anyone say that they want to ban all Kotlin from the Groovy
codebase for all time. What I am hearing is that given that there is only a
handful of characters difference between the build files in both languages,
the community doesn't think the extra Kotlin technical dependency is needed
right now. It's not pulling its weight yet. The community needs more time:

* to allow other contributors to come up to speed on Kotlin
* to work out the impacts on our Eclipse or NetBeans users where Kotlin
  support isn't quite as good
* to work out whether we can improve IDE support for the Groovy-DSL
  for Gradle ourselves in Eclipse, Intellij or NetBeans
* to understand how we can remain good advocates for using the Groovy-DSL
  for Gradle for users who haven't or don't want to swap (yet)

I can understand why working within the constraints of the Groovy community
be very frustrating but we value community very highly and we want to bring
the whole
community along for the journey. I know even I am frustrated at times but
I also see the many innovations that keep happening within the community and
the very talented individuals and welcoming spirit of the community that
it worthwhile for me.

For me personally, I'd like to see a version of Gradle using Groovy 3.
I think if you restricted yourself to a subset of Groovy and a subset of
you could possibly have a build file that was identical in both languages.
[There are just a few very minor things that might need work-arounds.]
But I am unlikely to have time to pursue that interest, so I remain
about how things might pan out down the track.

Cheers, Paul.

On Fri, Mar 22, 2019 at 12:43 PM Thibault Kruse <>

> [snip]

View raw message