groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andres Almiray <>
Subject Re: About Gradle, Kotlin and Inner Fear
Date Mon, 23 May 2016 12:02:21 GMT
Or you know, use XML as a DSL and put the Maven vs. Gradle discussion to
rest for good. (wink)

Joking aside, I'm aware that the tooling API has been improved a lot in
past released; how much remains to be seen, and how much of that API relies
on Groovy specific classes too.


Java Champion; Groovy Enthusiast
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

On Mon, May 23, 2016 at 1:59 PM, 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