[...] > I disagree a bit. It's not only about code completion, but also about jumping > to the definitions (and the documentation).
true, though.. I must say I found the gradle documentation for tasks quite lacking... maybe looking at the code would give better insights, so jumping might be more worth > Also commonly the copy-pasted part covers my use case to 90%, but then I > still want to adapt, want to know what additional options exist. you do and I do usually, sure. Why do you think I have seen so many gradle files? Because people ask me to help them adding those additional options ;) > One general problem is 3rd party plugin code exposing groovy classes in the > Api, like groovy.lang.Closure, or reliance on runtime dynamics. I think the part about Closure is more legacy. Today almost all of that can be done with SAM-conversion... reliance on runtime dynamics... I have actually not seen that very often. You have a differing experience? > Same in the future for kotlin constructs. Using those in Gradle files from > the other language (kotlin creating groovy closures or groovy creating kotlin > actions) is painful and looks horrible. which reminds me... what happened to "writing gradle files in javascript"? Anyway I do agree with the point, though... having a few invasive elements can be quite good for the language. > I don't know how Gradle Inc hopes to have a healthy plugin ecosystem that > does not force all plugin providers to obey strict limitations or provide 2 > DSLs or plugin. I mean you should always be able to write a plugin in Java. If you can write it in Java, you can write it in Groovy. If the kotlin DSL needs to be able to deal with plugins written in Java, then you can have Groovy written plugins in the same style. If this requires additional work to make the kotlin side see through the plugin structure, then well, then that is what will be done. But I do not know examples for this. We could probably provide a few transforms to generate the code kotlin needs to understand the plugin and encourage plugin writers to use Groovy that way - but this requires that we know what we are talking about. I do not really know the problems with the kotlin DSL well enough to assess something here atm. If you do, sharing details is appreciated. bye Jochen
