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 <mg...@arscreat.com> 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 < > sergio.del...@softamo.com> 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 <cedric.champ...@gmail.com> >> 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 <sergio.del...@softamo.com> >> 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) < >>> eric.mil...@thomsonreuters.com> 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? >>> >>> >
