First of all it would be nice of Cedric to explain what post it was that
triggered him like this. I still have trouble reading that post from MG
like that.
And sure there is a conflict of interests here, between Gradle and
Groovy. Gradle wants the best support for their developers for the
cheapest prize. And the choice is here between something seemingly
difficult to teach the IDEs and somebody else doing the work for/with
you, giving you a chance to modernize the DSL as well. Not wanting
sentimental thoughts getting in the way of business they did the right
choice in the long term. Of course realization reality and motivation
differ.
Cedric has always been on our side, making his stand in Gradle a
difficult one. It is no wonder he reacts harsh if somebody gives him the
impression he works against Groovy. If it was that post I am sure MG did
not mean it personal at all. And if it really was that post, it would be
a nice gesture of MG to apologize (even it was not ment like that) and
for Cedric to reconsider.
[...]
On 23.03.19 21:00, MG wrote:
On 22/03/2019 03:37, Thibault Kruse wrote:
On Thu, Mar 21, 2019 at 11:03 AM MG <mg...@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
I have read Cédric's post several times back then, and have reread it
now, and to me it says exactly that: It would have been possible to do
this in Groovy, just not by Cédric alone; e.g.:
"Does it make sense [to support Groovy in addition to Kotlin] ? Now that
we made the decision to support Kotlin, that we proved it would provide
the level of user friendliness we want and that it is statically
compiled by default, does it make sense to put resources to support
static Groovy in addition? I don’t have an answer to this. I thought
yes, but now I’m not sure. Kotlin does the job. And honestly, they have
great engineers working on the language."
Well, what exactly are the differences between the new DSL and the
Groovy DSL? I am not talking about the potential differences. I am
talking about the existing differences for non-core plugins.
The examples I have seen so far look like Groovy rewrites with small
changes. Does somebody have a link on how to write a Gradle plugin that
then will have the IDE support in Kotlin scripts? Do these plugins have
to be in Kotlin for example?
How are recent developments in that DSL?
In addition it has been confirmed here by other Groovy stalwarts that
Gradle wanted changes in (the static part of) Groovy, which the project
just could not deliver with the manpower available.
what changes was that again? I mark JavaOne 2015 as the beginning of
this (https://blog.jetbrains.com/kotlin/2016/05/gradle-meets-kotlin/).
That was the same year of the Pivotal layoffs forcing all of the members
paid to officially develop Groovy into new Jobs and no company being
able or willing to leverage the former team as whole or in parts to keep
working on Groovy.
Jetbrains had a
choice, and they decided to go along the Kotlin route, and they offered
that plus excellent IDE support to the Gradle people, who took it. As I
have said before: Commercially all completely understandable - but at
the same time it put them in direct competition with Groovy, with the
fact that IntelliJ is the IDE for Groovy development making matters
infinitely more complicated.
It is not like the Kotlin people spending all their time on making a
better DSL for Gradle. Otherwise it would not take that long for that
Kotlin DSL to develop. But since I am not actively following that
development I may have missed the great things they made possible in the
meantime.
bye Jochen
