groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jochen Theodorou" <blackd...@gmx.org>
Subject Aw: Re: Binary compatibility fixed + Kotlin DSL
Date Wed, 03 Apr 2019 14:52:36 GMT
[...] 
> 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
 

Mime
View raw message