groovy-users mailing list archives

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

> 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 <>
> 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:
> >
> >
> > 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
> >

View raw message