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 anything 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 political 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 could 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 then I also see the many innovations that keep happening within the community and the very talented individuals and welcoming spirit of the community that makes 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 Kotlin 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 pragmatic about how things might pan out down the track. Cheers, Paul. On Fri, Mar 22, 2019 at 12:43 PM Thibault Kruse <tibokr...@googlemail.com> wrote: > [snip]
