On Wed, Apr 3, 2019, 01:56 Jochen Theodorou <blackd...@gmx.org> wrote:
> Hi, > > I have never used it, but what you write is within my expectations. We > should not forget we are *still* (after years) talking about an early > version of the DSL. > > My experience with other people doing gradle is more like this: > There is a problem, we search on stackoverflow and copy+paste the > solution to see if it works. If it does great, if not, search again. > Most do not try to understand the logic behind. And I can't blame > people, I do similar things when I have to deal with maven builds... > Only that maven does not expose internal logic directly and often you > are lost fast, while gradle would in theory allow you to learn how it > works gradually. Anyway... in cases like that you rarely care about code > completion. > I disagree a bit. It's not only about code completion, but also about jumping to the definitions (and the documentation). 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. One general problem is 3rd party plugin code exposing groovy classes in the Api, like groovy.lang.Closure, or reliance on runtime dynamics. 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. 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. >
