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 14:23:56 GMT
If you are interested in the static Groovy DSL for Gradle, I suggest you
give my branch a try:
https://github.com/gradle/gradle/tree/cc-static-gradle-build

2016-05-23 16:15 GMT+02:00 Thibault Kruse <tibokruse@googlemail.com>:

> 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