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 <tibokr...@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.champ...@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 <tibokr...@googlemail.com>: > >> > >> > 2016-05-23 13:59 GMT+02:00 Thibault Kruse <tibokr...@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.champ...@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.champ...@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 <tibokr...@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 <blackd...@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 > >> >> > > >> > > >> > > > > > >
