Re: [OT] Old Mailing-list on Nabble

[Guillaume Laforge]

Good question.
Could you reach out to the Nabble guys to see how this can be done?
http://www.nabble.com/ContactUs.jtp
Their support forum should be helpful.
The founders have been very helpful with me in the past when setting up the
forum.

Guillaume

On Mon, May 23, 2016 at 5:09 PM, Benjamin Gudehus 
wrote:

> Hey,
>
> for (nearly) every message to the Apache Groovy Mailing-lists I receive
> two mails (one from groovy.apache.org and one from n5.nabble.com).
>
> Unfortunately the URL to the Nabble forum on [1] redirects to [1] itself.
> Which means I can't use the Nabble user interface to unsubscribe (if there
> was any).
> Clicking on the unsubscribe link in the footer of the mails does the same.
>
> I wonder if there's a way to unsubscribe. If not, as a work-around, I'll
> filter all mails from n5.nabble.com that contain the text "
> groovy.329449.n5.nabble.com".
>
> [1] http://www.groovy-lang.org/mailing-lists.html
>
> Regards,
> Benjamin
>
>


-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Product Ninja & Advocate at Restlet 

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

Re: About Gradle, Kotlin and Inner Fear

[Jochen Theodorou]

@DelegatesTo should be understood by Idea and I thought by Eclipse too

On 23.05.2016 16:52, Cédric Champeau wrote:

It is enough for step one. I already had problems with it (discovered
some bugs in the type checker...), but it should be ok. We need to make
sure we have delegated properties too (aka, that extension methods work
if you define get/set methods). It doesn't solve the issue of IDE
support, though :(

2016-05-23 16:43 GMT+02:00 Jochen Theodorou mailto:blackd...@gmx.org>>:

On 23.05.2016 16:35, Cédric Champeau wrote:

Yes, "local" extension methods are a very powerful tool. For example
extensions that are scoped to a class (and optionally its
sub-classes).
Static discoverability is important.


but assuming we had that... what would be missing? Why is
@DelegatesTo not enough for static builder for example?

bye Jochen

Re: About Gradle, Kotlin and Inner Fear

[Balachandran Sivakumar]

Hi Cedric,

On Mon, May 23, 2016 at 5:27 PM, Cédric Champeau 
wrote:

> there's absolutely no need for an external DSL descriptor: all the
>> constructs of the language, like extension methods or static builders are
>> first class language features. The issue is, IDE support for Groovy is
>> lacking (Groovy Eclipse is dead, IntelliJ needs to know specifics of static
>> Gradle/Groovy scripts, ...)
>
>
If we have to resurrect it, what would it take ? I mean, what skill
set/knowledge should someone have to work on it and resurrect it ? Also,
can someone here help with that effort ? Thanks



-- 
Thank you
Balachandran Sivakumar

[OT] Old Mailing-list on Nabble

[Benjamin Gudehus]

Hey,

for (nearly) every message to the Apache Groovy Mailing-lists I receive two
mails (one from groovy.apache.org and one from n5.nabble.com).

Unfortunately the URL to the Nabble forum on [1] redirects to [1] itself.
Which means I can't use the Nabble user interface to unsubscribe (if there
was any).
Clicking on the unsubscribe link in the footer of the mails does the same.

I wonder if there's a way to unsubscribe. If not, as a work-around, I'll
filter all mails from n5.nabble.com that contain the text "
groovy.329449.n5.nabble.com".

[1] http://www.groovy-lang.org/mailing-lists.html

Regards,
Benjamin

Re: About Gradle, Kotlin and Inner Fear

[Cédric Champeau]

It is enough for step one. I already had problems with it (discovered some
bugs in the type checker...), but it should be ok. We need to make sure we
have delegated properties too (aka, that extension methods work if you
define get/set methods). It doesn't solve the issue of IDE support, though
:(

2016-05-23 16:43 GMT+02:00 Jochen Theodorou :

> On 23.05.2016 16:35, Cédric Champeau wrote:
>
>> Yes, "local" extension methods are a very powerful tool. For example
>> extensions that are scoped to a class (and optionally its sub-classes).
>> Static discoverability is important.
>>
>
> but assuming we had that... what would be missing? Why is @DelegatesTo not
> enough for static builder for example?
>
> bye Jochen
>

Re: About Gradle, Kotlin and Inner Fear

[Jochen Theodorou]

On 23.05.2016 16:35, Cédric Champeau wrote:

Yes, "local" extension methods are a very powerful tool. For example
extensions that are scoped to a class (and optionally its sub-classes).
Static discoverability is important.


but assuming we had that... what would be missing? Why is @DelegatesTo 
not enough for static builder for example?


bye Jochen

Re: About Gradle, Kotlin and Inner Fear

[Jochen Theodorou]

On 23.05.2016 13:59, Thibault Kruse wrote:

It seems that Groovy already lost at Gradle, both Gradle and Pivotal
bet against Groovy.


Pivotal was never really on our side. They looked for something to make 
money with out of a portfolio of not money making projects in EMC and 
Vmware mostly, to concentrate on that and abandon the others. So in case 
of Groovy and Grails it was only ballast to them and they have been 
looking for a way out. So they don't bet against us, as much as they 
never did bet on us.


bye Jochen

Re: About Gradle, Kotlin and Inner Fear

[Cédric Champeau]

Yes, "local" extension methods are a very powerful tool. For example
extensions that are scoped to a class (and optionally its sub-classes).
Static discoverability is important.

2016-05-23 16:30 GMT+02:00 Jochen Theodorou :

> On 23.05.2016 13:57, Cédric Champeau wrote:
>
>>
>>
>> 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.
>>
>> I made it very clear in my blog post: the Kotlin DSL is based on a new
>> API that the static Groovy DSL could use too. That's not an issue. But
>> Kotlin makes it significantly easier for IDEs because it is statically
>> compiled, and therefore there's absolutely no need for an external DSL
>> descriptor: all the constructs of the language, like extension methods
>> or static builders are first class language features. The issue is, IDE
>> support for Groovy is lacking (Groovy Eclipse is dead, IntelliJ needs to
>> know specifics of static Gradle/Groovy scripts, ...)
>>
>
> I was thinking about our extension methods as well as annotated closures
> parameters. In my opinion we have the basics there, so the question is how
> o make it more easy to use for the static compiler. Like having an import
> for a static extension method container and reducing the scope ... aka
> static categories. And so on.
>
> Bye Jochen
>
>
>
>

Re: About Gradle, Kotlin and Inner Fear

[Jochen Theodorou]

On 23.05.2016 13:57, Cédric Champeau wrote:



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.

I made it very clear in my blog post: the Kotlin DSL is based on a new
API that the static Groovy DSL could use too. That's not an issue. But
Kotlin makes it significantly easier for IDEs because it is statically
compiled, and therefore there's absolutely no need for an external DSL
descriptor: all the constructs of the language, like extension methods
or static builders are first class language features. The issue is, IDE
support for Groovy is lacking (Groovy Eclipse is dead, IntelliJ needs to
know specifics of static Gradle/Groovy scripts, ...)


I was thinking about our extension methods as well as annotated closures 
parameters. In my opinion we have the basics there, so the question is 
how o make it more easy to use for the static compiler. Like having an 
import for a static extension method container and reducing the scope 
... aka static categories. And so on.


Bye Jochen

Re: About Gradle, Kotlin and Inner Fear

[Cédric Champeau]

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 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
>  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
> 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 :
> >>
> >> > 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 language
> >> >> to define builds.
> >> On Mon, May 23, 2016 at 9:05 PM, Cédric 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édric Champeau
> >>  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 :
> >> >>
> >> >> 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
> >> >

Re: About Gradle, Kotlin and Inner Fear

[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 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
 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 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 :
>>
>> > 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 language
>> >> to define builds.
>> On Mon, May 23, 2016 at 9:05 PM, Cédric 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édric Champeau
>>  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 :
>> >>
>> >> 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 

Re: About Gradle, Kotlin and Inner Fear

[Cédric Champeau]

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 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 :

> > 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 language
> >> to define builds.
> On Mon, May 23, 2016 at 9:05 PM, Cédric 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édric Champeau
>  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 :
> >>
> >> 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 c

Re: About Gradle, Kotlin and Inner Fear

[Thibault Kruse]

On Mon, May 23, 2016 at 9:05 PM, Schalk Cronjé  wrote:
> This sounds too much like maven-polyglot to me.

I think more along the lines of python setuptools. This is just a
python library, and it is called from python scripts like any other
python library. Why should Gradle not go that way, provide a library
for any JVM language to consume?

It is not quite like polyglot maven.

However, I also often think that it would also be useful if there was
a purely declarative DSL for programmatic builds that any buildsystem
could advertize to any IDE to describe the bits of the build relevant
to the IDE (e.g. all jars involved as dependencies with their
respective scopes, and maybe shell commands to invoke to process
certain tasks the IDE should not attempt to replicate).

Because that is the other problem of Gradle integration with any IDE;
that the IDE has to *execute* the build.gradle to find out e.g. the
dependency structure.

Re: About Gradle, Kotlin and Inner Fear

[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 language
>> to define builds.
On Mon, May 23, 2016 at 9:05 PM, Cédric 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édric Champeau
 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 :
>>
>> 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:
>> > 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 wor

Re: About Gradle, Kotlin and Inner Fear

[Cédric Champeau]

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 :

> 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:
> > 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
> >
>

Re: About Gradle, Kotlin and Inner Fear

[Schalk Cronjé]

On 23/05/2016 12:59, Thibault Kruse wrote:

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.


*cringe*

This sounds too much like maven-polyglot to me.


--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r

Re: About Gradle, Kotlin and Inner Fear

[Andres Almiray]

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 
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 
> 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
> >
>

Re: About Gradle, Kotlin and Inner Fear

[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:
> 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
>

Re: About Gradle, Kotlin and Inner Fear

[Cédric Champeau]

>
>
>
> 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.
>
> I made it very clear in my blog post: the Kotlin DSL is based on a new API
that the static Groovy DSL could use too. That's not an issue. But Kotlin
makes it significantly easier for IDEs because it is statically compiled,
and therefore there's absolutely no need for an external DSL descriptor:
all the constructs of the language, like extension methods or static
builders are first class language features. The issue is, IDE support for
Groovy is lacking (Groovy Eclipse is dead, IntelliJ needs to know specifics
of static Gradle/Groovy scripts, ...)

We can discuss that during GR8Conf if you will. GDSL is definitely not an
option: it's far from being enough, and too slow. And it wouldn't solve the
issues with the current DSL. So a new DSL is designed, and Kotlin has been
chosen because it's static first and has supported IDEs (both IDEA and
Eclipse). I can make a static Groovy DSL, it wouldn't change this fact.

Re: About Gradle, Kotlin and Inner Fear

[Jochen Theodorou]

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

Re: About Gradle, Kotlin and Inner Fear

[Thibault Kruse]

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.


On Monday, May 23, 2016, Schalk Cronjé  wrote:

> As a follow-up to Dan Woods post regarding reactions of the ApacheGroovy
> community to the recent announcement of Kotlin support in Gradle, I had
> posted the following
>
>
> http://delivervalue.blogspot.co.uk/2016/05/about-gradle-kotlin-and-inner-fear.html
>
> in the hope that it will elicit more conversation regarding the state of
> the Groovy nation.
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>
>