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 11:59:52 GMT
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