groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <tibokr...@googlemail.com>
Subject Re: About Gradle, Kotlin and Inner Fear
Date Mon, 23 May 2016 14:15:52 GMT
Creating a static Groovy DSL even as a mere unofficial experimental
branch for now may help improve the level1 API and prevent too much
functionality from moving into level 2. This is generally beneficial,
because there is no telling what way Kotlin will go (e.g. sliding into
a Python2/3 incompatibility scenario). It's easy to get excited about
unconventional language features, but if anything, the current
situation shows the technical debt that accumulates when moving away
from mere java in any API.

Regarding Closures, I guess there are also 3rdparty plugins with
methods accepting Object, List, Array, and Clojure, trying to do
polymorphism without interfaces. Not sure how much core gradle has
that, but the plugin landscape is also vast indeed.

At the time I wrote my own gradle plugin, I did need some horrible casting:
https://github.com/tkruse/gradle-groovysh-plugin/blob/master/src/main/groovy/com/tkruse/gradle/groovysh/DynamicInvokeHelper.groovy
not sure how much of it could be cleaned up now, but I want to stay
backwards compatible anyway, so a better new API only helps so much.


On Mon, May 23, 2016 at 10:05 PM, Cédric Champeau
<cedric.champeau@gmail.com> wrote:
> Basically, some of the Gradle core classes are still using `Closure` as a
> last parameter, which doesn't make them usable in Java, Kotlin, or
> statically compiled Groovy. For a long time now, those methods are being
> replaced in Gradle by "language agnostic" interfaces: Action<Foo> instead of
> Closure (which is related to the thread I launched a few days ago about
> delegation strategy for automatic closure coercion). This is the absolute
> minimal thing that Java needs, Kotlin needs, and to some extent static
> Groovy need so that we can write plugins in those languages without relying
> on very dirty code (new Closure(this) { ...insert some casts and reflective
> code here... }).
>
> This is the "level 1" api. But it doesn't make a new static DSL. The layer 2
> is language specific. Kotlin will use extension methods, static builders,
> ... while my experiment in Groovy uses extension modules. So when we work on
> level 1, we're improving the experience for all static languages, and that
> allows each language to put its own DSL layer on top of that. Kotlin first.
> There's no plan for a static Groovy DSL at Gradle for now (this could
> change), for the reasons I explained in my blog post (IDE support, duplicate
> work, ...).
>
> 2016-05-23 14:27 GMT+02:00 Thibault Kruse <tibokruse@googlemail.com>:
>>
>> > 2016-05-23 13:59 GMT+02:00 Thibault Kruse <tibokruse@googlemail.com>:
>> >>
>> >> It would be more interesting to investigate whether Gradle could
>> >> provide a programmatic API that allows easily using any JVM language
>> >> to define builds.
>> On Mon, May 23, 2016 at 9:05 PM, Cédric Champeau
>> <cedric.champeau@gmail.com> wrote:
>> > Thibault, this is exactly what Gradle is doing. ...
>>
>> In that case, there are two possibilitities. Either in all the
>> documentation, both Groovy and Kotlin will use the new, improved API.
>> Which probably implies lack of backwards compatibility, so all
>> build.gradle scripts have to be adapted when upgrading.
>>
>> Or, Kotlin will use the new improved API in the documentation, whereas
>> the Groovy examples will keep the old API, meaning the old API is also
>> available from Kotlin (causing mess and confusion).
>>
>> Could you clarify that?
>>
>>
>>
>>
>>
>> On Mon, May 23, 2016 at 9:05 PM, Cédric Champeau
>> <cedric.champeau@gmail.com> wrote:
>> > Thibault, this is exactly what Gradle is doing. The Kotlin support is
>> > the
>> > occasion to provide better APIs that are more friendly to static
>> > languages.
>> > In my post I have shown an example of the static Groovy version. The
>> > question is not whether we can do it or not. We can do it. The issue is
>> > IDE
>> > support. Have this scripts recognized by the IDE as such. Have a decent
>> > version of Groovy Eclipse. That is the challenge. The latter is
>> > important. I
>> > warned several times about the problem that nobody took over the
>> > development
>> > of Groovy Eclipse. If nobody does it, I bet that you can improve Groovy
>> > as
>> > much as you want, fix as many bugs as you want or add as many awesome
>> > features as you want, it's not going to be adopted anymore.
>> >
>> > 2016-05-23 13:59 GMT+02:00 Thibault Kruse <tibokruse@googlemail.com>:
>> >>
>> >> It seems that Groovy already lost at Gradle, both Gradle and Pivotal
>> >> bet against Groovy.
>> >>
>> >> It would be more interesting to investigate whether Gradle could
>> >> provide a programmatic API that allows easily using any JVM language
>> >> to define builds. Such that one may write a build.groovy instead of a
>> >> build.gradle, statically compiled, running against the gradle API.
>> >> Such that no custom editor besides a standard Groovy editor would be
>> >> needed in the first place. And there would be nothing stopping people
>> >> from writing build scripts in other languages like scala or clojure.
>> >> Maybe that's already possible, but my impression has been that the
>> >> current Gradle API is not that great to program against, nor is it
>> >> clear which parts are public API that can be relied upon and which
>> >> parts are internal and likely to change.
>> >>
>> >> That approach would also be more future-proof.
>> >>
>> >> On Mon, May 23, 2016 at 8:38 PM, Jochen Theodorou <blackdrag@gmx.org>
>> >> wrote:
>> >> > On 23.05.2016 10:59, Thibault Kruse wrote:
>> >> >>
>> >> >> Cedric's comment linked at the bottom of that post is excellent
in
>> >> >> describing the issue. The gradle DSL has been designed in a way
that
>> >> >> is
>> >> >> hard to support by IDEs, partly because groovy made that so easy.
>> >> >>
>> >> >> And the same might be true about other popular groovy frameworks.
>> >> >> Having
>> >> >> to support plugins for each IDE for each framework specific DSL
is
>> >> >> not
>> >> >> viable.
>> >> >>
>> >> >> If there were a lesson to be learned here for a vastly different
>> >> >> groovy
>> >> >> 3, it is hard to imagine that in practice those lessons could be
>> >> >> applied.
>> >> >
>> >> >
>> >> > The lesson would be to have static typed DSLs, and if you want to be
>> >> > language implementation agnostic, you need the description in
>> >> > something
>> >> > anyone can read. So the maximum that is allowed is annotations of
>> >> > some
>> >> > kind
>> >> > - or a DSL to describe the DSL.
>> >> >
>> >> > The later exists, is called GDSL, and even though IDE specific, it
is
>> >> > not
>> >> > very well supported by the same IDEs.
>> >> >
>> >> > And what we have in first possibility might be on par with many other
>> >> > DSL
>> >> > supporting languages, but not working out well enough for Gradle.
>> >> > That
>> >> > is,
>> >> > if you want to keep the DSL as is.
>> >> >
>> >> > I am wondering more about something like this:
>> >> > http://mrhaki.blogspot.de/2013/05/gradle-goodness-extending-dsl.html
>> >> >
>> >> > So if that basically means adding new DSL parts to any arbitrary (but
>> >> > ExtensionAware) element in the build system. Then you need to define
>> >> > a
>> >> > way
>> >> > to connect that in a static way for a static view to be able to do
>> >> > static
>> >> > checks. I guess that would be extension functions then.. The
>> >> > difference
>> >> > between their extension functions and our extension methods is, that
>> >> > theirs
>> >> > is potentially more easy to use, since you do not need to produce a
>> >> > descriptor. There was never really a need for that so far in Groovy,
>> >> > but
>> >> > it
>> >> > certainly could be implemented. The static compiler already
>> >> > understands
>> >> > extension methods, so it would be just a matter of a different
>> >> > descriptor of
>> >> > some kind, plus making that available at compile time.
>> >> >
>> >> > I really would like to see a gradle DSL example in Kotlin that cannot
>> >> > made
>> >> > static checked in Groovy. Because things like accessing dynamic
>> >> > properties
>> >> > won´t work in Kotlin as well.
>> >> >
>> >> > If they really wanted to there would be a way.
>> >> >
>> >> > bye Jochen
>> >> >
>> >
>> >
>
>

Mime
View raw message