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. Cheers, Andres ------------------------------------------- Java Champion; Groovy Enthusiast http://jroller.com/aalmiray http://www.linkedin.com/in/aalmiray -- 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 <tibokr...@googlemail.com> wrote: > 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 > > >
