Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 5E1AE2009F9 for ; Mon, 23 May 2016 16:24:02 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 5CD591609A8; Mon, 23 May 2016 14:24:02 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3130F1602C5 for ; Mon, 23 May 2016 16:24:01 +0200 (CEST) Received: (qmail 47994 invoked by uid 500); 23 May 2016 14:24:00 -0000 Mailing-List: contact users-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.apache.org Delivered-To: mailing list users@groovy.apache.org Received: (qmail 47983 invoked by uid 99); 23 May 2016 14:24:00 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 May 2016 14:24:00 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id E35751804D3 for ; Mon, 23 May 2016 14:23:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.179 X-Spam-Level: ** X-Spam-Status: No, score=2.179 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id oFepJL00Kaam for ; Mon, 23 May 2016 14:23:57 +0000 (UTC) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 0D8885FE43 for ; Mon, 23 May 2016 14:23:57 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id n129so81781374wmn.1 for ; Mon, 23 May 2016 07:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=H5L6GtbDIaLJVrW1hQ8XO3k6z/3dB1VpP+BdKftWl9Y=; b=ZgJhBqCjctqkDUMdRWW65jjWWEm1Z9iaOMT1TpEYVLwU2sLwn9IuTKPZeEN1O3F1TY MCCbdYWpT4rJTTcf7xCUXPjn0rXJcK6Tw6Bj+URj62hWMDWCEvsuZofCmiaBHBl5xSty I9QKI9lEJzycphddbgOpkdymJM5XMMVVqxCoGf/zlnbRYqYk777KPu9xSn1/ffZlQAXd 1Ey2sIyvDXjQ0LeLj1GkDlZXbTPmO/KPOiqgmEVwXCX0Mk3TboMGl3Fb3upOAGE0W/bo 2kB5bPCNAxU2t2kJflirESvGZs4fTlhbzgdjcSNMYJwC9XzvKfXH4KDrlWmAhXOm9dGU n1Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=H5L6GtbDIaLJVrW1hQ8XO3k6z/3dB1VpP+BdKftWl9Y=; b=KII0H13IDdziGk+D+h1rCPqvLyHIkShIn5P1TwP0gkzjIyIo6EhEdx/zYO4xx93uu2 vo82IF1YDh3yqzOE8lvwY51X3CJ4GzwvVEMGuWYTMKQHnKADEsllWyv7TSO/eIDYSUHz ZpiL5Igm2N9vv0AzYldh3jZPnpUAZRVjjvwul6nE7lqXg4tjDgAIOBeFNinEnGl3yD4q ExacGGkFfSxfzipXI1JCFKzUL6URCeYJZviYymuMBHYgJVXdxUu82LOhJucMvdLkpJ+z O6ivfLtp51Gd1wVe26LGc8KXTk0qJ/xHF3qAQV84aymvPW7d1tOSGw2rSPDgpj95/Qzd zKYg== X-Gm-Message-State: AOPr4FWmqzQ4eysW/MtUeENAreJ6O4XnzwlnsdcrGJFkN3dmKVOij4n0JuVNnGkEW6YrmAwP0hdEPmcLcp3M0w== MIME-Version: 1.0 X-Received: by 10.28.153.80 with SMTP id b77mr17787459wme.71.1464013436667; Mon, 23 May 2016 07:23:56 -0700 (PDT) Received: by 10.28.105.220 with HTTP; Mon, 23 May 2016 07:23:56 -0700 (PDT) In-Reply-To: References: <7421d291-23af-0dac-a54f-9c6e24f49e82@gmail.com> <5742EBC6.7080609@gmx.org> Date: Mon, 23 May 2016 16:23:56 +0200 Message-ID: Subject: Re: About Gradle, Kotlin and Inner Fear From: =?UTF-8?Q?C=C3=A9dric_Champeau?= To: users@groovy.apache.org Content-Type: multipart/alternative; boundary=001a114b3100d70a5a05338330f3 archived-at: Mon, 23 May 2016 14:24:02 -0000 --001a114b3100d70a5a05338330f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 : > 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 castin= g: > > https://github.com/tkruse/gradle-groovysh-plugin/blob/master/src/main/gro= ovy/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=C3=A9dric Champeau > 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 bein= g > > replaced in Gradle by "language agnostic" interfaces: Action > 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 absolu= te > > 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 builder= s, > > ... 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 : > >> > >> > 2016-05-23 13:59 GMT+02:00 Thibault Kruse = : > >> >> > >> >> It would be more interesting to investigate whether Gradle could > >> >> provide a programmatic API that allows easily using any JVM languag= e > >> >> to define builds. > >> On Mon, May 23, 2016 at 9:05 PM, C=C3=A9dric Champeau > >> 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=C3=A9dric Champeau > >> wrote: > >> > Thibault, this is exactly what Gradle is doing. The Kotlin support i= s > >> > 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 awesom= e > >> > 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 Pivota= l > >> >> bet against Groovy. > >> >> > >> >> It would be more interesting to investigate whether Gradle could > >> >> provide a programmatic API that allows easily using any JVM languag= e > >> >> 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 b= e > >> >> needed in the first place. And there would be nothing stopping peop= le > >> >> 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, i= t > 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 d= o > >> >> > 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=C2=B4t work in Kotlin as well. > >> >> > > >> >> > If they really wanted to there would be a way. > >> >> > > >> >> > bye Jochen > >> >> > > >> > > >> > > > > > > --001a114b3100d70a5a05338330f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you are interested in the static Groovy DSL for Gradle,= I suggest you give my branch a try:=C2=A0https://github.com/gradle/gradle/tr= ee/cc-static-gradle-build

2016-05-23 16:15 GMT+02:00 Thibault Kruse <tibokr= use@googlemail.com>:
Creati= ng 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-plu= gin/blob/master/src/main/groovy/com/tkruse/gradle/groovysh/DynamicInvokeHel= per.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=C3=A9dric Champeau
<cedric.champeau@gmail.com> wrote:
> Basically, some of the Gradle core classes are still using `Closure` a= s a
> last parameter, which doesn't make them usable in Java, Kotlin, or=
> statically compiled Groovy. For a long time now, those methods are bei= ng
> replaced in Gradle by "language agnostic" interfaces: Action= <Foo> instead of
> Closure (which is related to the thread I launched a few days ago abou= t
> delegation strategy for automatic closure coercion). This is the absol= ute
> minimal thing that Java needs, Kotlin needs, and to some extent static=
> Groovy need so that we can write plugins in those languages without re= lying
> on very dirty code (new Closure(this) { ...insert some casts and refle= ctive
> code here... }).
>
> This is the "level 1" api. But it doesn't make a new sta= tic DSL. The layer 2
> is language specific. Kotlin will use extension methods, static builde= rs,
> ... while my experiment in Groovy uses extension modules. So when we w= ork 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 f= irst.
> There's no plan for a static Groovy DSL at Gradle for now (this co= uld
> change), for the reasons I explained in my blog post (IDE support, dup= licate
> work, ...).
>
> 2016-05-23 14:27 GMT+02:00 Thibault Kruse <tibokruse@googlemail.com>:
>>
>> > 2016-05-23 13:59 GMT+02:00 Thibault Kruse <tibokruse@googlemail.com>:
>> >>
>> >> It would be more interesting to investigate whether Gradl= e could
>> >> provide a programmatic API that allows easily using any J= VM language
>> >> to define builds.
>> On Mon, May 23, 2016 at 9:05 PM, C=C3=A9dric Champeau
>> <cedric.champeau@g= mail.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 A= PI.
>> 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, whe= reas
>> 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=C3=A9dric Champeau
>> <cedric.champeau@g= mail.com> wrote:
>> > Thibault, this is exactly what Gradle is doing. The Kotlin su= pport is
>> > the
>> > occasion to provide better APIs that are more friendly to sta= tic
>> > languages.
>> > In my post I have shown an example of the static Groovy versi= on. The
>> > question is not whether we can do it or not. We can do it. Th= e issue is
>> > IDE
>> > support. Have this scripts recognized by the IDE as such. Hav= e 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 impr= ove 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 anymor= e.
>> >
>> > 2016-05-23 13:59 GMT+02:00 Thibault Kruse <tibokruse@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 Gradl= e could
>> >> provide a programmatic API that allows easily using any J= VM language
>> >> to define builds. Such that one may write a build.groovy = instead of a
>> >> build.gradle, statically compiled, running against the gr= adle API.
>> >> Such that no custom editor besides a standard Groovy edit= or would be
>> >> needed in the first place. And there would be nothing sto= pping 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 tha= t post is excellent in
>> >> >> describing the issue. The gradle DSL has been de= signed in a way that
>> >> >> is
>> >> >> hard to support by IDEs, partly because groovy m= ade that so easy.
>> >> >>
>> >> >> And the same might be true about other popular g= roovy frameworks.
>> >> >> Having
>> >> >> to support plugins for each IDE for each framewo= rk 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 i= f you want to be
>> >> > language implementation agnostic, you need the descr= iption in
>> >> > something
>> >> > anyone can read. So the maximum that is allowed is a= nnotations of
>> >> > some
>> >> > kind
>> >> > - or a DSL to describe the DSL.
>> >> >
>> >> > The later exists, is called GDSL, and even though ID= E specific, it is
>> >> > not
>> >> > very well supported by the same IDEs.
>> >> >
>> >> > And what we have in first possibility might be on pa= r with many other
>> >> > DSL
>> >> > supporting languages, but not working out well enoug= h for Gradle.
>> >> > That
>> >> > is,
>> >> > if you want to keep the DSL as is.
>> >> >
>> >> > I am wondering more about something like this:
>> >> > http://mr= haki.blogspot.de/2013/05/gradle-goodness-extending-dsl.html
>> >> >
>> >> > So if that basically means adding new DSL parts to a= ny arbitrary (but
>> >> > ExtensionAware) element in the build system. Then yo= u 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 th= en.. The
>> >> > difference
>> >> > between their extension functions and our extension = methods is, that
>> >> > theirs
>> >> > is potentially more easy to use, since you do not ne= ed to produce a
>> >> > descriptor. There was never really a need for that s= o 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 tim= e.
>> >> >
>> >> > I really would like to see a gradle DSL example in K= otlin that cannot
>> >> > made
>> >> > static checked in Groovy. Because things like access= ing dynamic
>> >> > properties
>> >> > won=C2=B4t work in Kotlin as well.
>> >> >
>> >> > If they really wanted to there would be a way.
>> >> >
>> >> > bye Jochen
>> >> >
>> >
>> >
>
>

--001a114b3100d70a5a05338330f3--