groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: About Gradle, Kotlin and Inner Fear
Date Mon, 23 May 2016 13:05:55 GMT
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