Re: Groovy 2.5.0-rc-2 breaks Gant

[Paul King]

Short answer is we can have as many RCs as needed to get it right but we
don't really want to be chopping and changing too much. Big changes are
supposed to be settling down by now - fate just brought this change late in
the game compared to what we'd like. I'd really like to get +ve feedback
from a SNAPSHOT with that change before doing another release including it.
I can merge in a couple of days time after conference commitments.

Cheers, Paul.

On Tue, May 8, 2018 at 2:27 PM, Remko Popma  wrote:

>
> I realize now that simply removing the `parser` and `formatter` properties
> was a mistake. While the picocli version of CliBuilder cannot use
> commons-cli classes I should have anticipated that some applications are
> setting these properties.
>
> I believe that I have a solution that provides a smoother migration path.
> PR
> https://github.com/apache/groovy/pull/696 adds dummy setters for the
> legacy properties.
>
> This should significantly reduce the disruption for applications like Gant
> that depend on the ability to modify these commons-cli properties in
> CliBuilder.
>
> Would it be possible to have another 2.5-rc release with the above change
> and see what the community feedback is before we decide to revert the
> CliBuilder delegation to point to the commons-cli implementation?
>
> Marking the delegation version class as deprecated is probably a good idea
> regardless of where it points to.
>
> Remko
>
>
> On Tue, May 8, 2018 at 3:19 Paul King  wrote:
>
>>
>> Both CliBuilder implementations are there via their full package names,
>> so encouraging people to use the non-delegated implementation of their
>> choice is a good option. They will need to get used to such changes in
>> Groovy 3 anyway.
>>
>> For Groovy 3, we might have a way for the compiler to translate from the
>> existing package names to the new ones brought about by JDK9 modules, in
>> which case we'd do that for CliBuilder and we'd want to point it to the
>> picocli package name by then (though if we do the change below we perhaps
>> wouldn't include CliBuilder in the translations list).
>>
>> For 2.5, we don't have the package translation in place and don't intend
>> to. Because of that, the point of the delegation version is to aid in
>> migration.
>> Maybe it was too big a jump to try to delegate to the Picocli delegation
>> in 2.5. If we find too many problems I think I should revert that change
>> and delegate to the commons cli implementation instead but mark the whole
>> delegation version class as deprecated.
>>
>> Let me know what people think.
>>
>> Cheers, Paul.
>>
>>
>> On Mon, May 7, 2018 at 3:45 PM, Keegan Witt  wrote:
>>
>>> I'll take a look.  I'll also see if there are other places that can
>>> break.
>>>
>>> If there are several ways it can break, then maybe we should not use a
>>> delegate to picocli and instead have folks switch the CliBuilder instance
>>> they instantiate.
>>>
>>> -Keegan
>>>
>>> On Sun, May 6, 2018, 7:56 PM Remko Popma  wrote:
>>>
 I think I found a way to fix this.
 See https://github.com/apache/groovy/pull/696
 This PR adds CliBuilder.setParser and CliBuilder.setFormatter methods
 that ignore the specified value and print a warning to stderr.

 On Sun, May 6, 2018 at 9:14 PM, Remko Popma 
 wrote:

> In 2.5.0-rc-2, groovy.util.CliBuilder delegates to
> groovy.cli.picocli.CliBuilder. The error is that the `parser` property of
> this class is no longer writable.
>
> You can resolve this with 2.5.0-rc-2 by either not setting the
> `parser` property in the CliBuilder constructor or using the
> groovy.cli.commons.CliBuilder instead.
>
> On the Groovy side I’m not sure what the best way is to make the
> transition easier.  The picocli version of CliBuilder can not make use of
> the Commons-CLI parser class.  We could modify CliBuilder to silently
> ignore the specified parser.  (We’d have to rename the picocli ParserSpec
> `parser` property in CliBuilder to something else.)
>
> Thoughts?
>
>
> On Sun, May 6, 2018 at 20:35 Keegan Witt  wrote:
>
>> FYI 2.5.0-rc-2 breaks Gant.  Specifically, it's caused by changing
>> groovy.util.CliBuilder to use Picocli
>>
>> java.lang.reflect.InvocationTargetException
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.codehaus.groovy.tools.GroovyStarter.rootLoader(
>> GroovyStarter.java:114)
>> at org.codehaus.groovy.tools.GroovyStarter.main(
>> 

Re: Groovy 2.5.0-rc-2 breaks Gant

[Remko Popma]

I realize now that simply removing the `parser` and `formatter` properties
was a mistake. While the picocli version of CliBuilder cannot use
commons-cli classes I should have anticipated that some applications are
setting these properties.

I believe that I have a solution that provides a smoother migration path.
PR
https://github.com/apache/groovy/pull/696 adds dummy setters for the legacy
properties.

This should significantly reduce the disruption for applications like Gant
that depend on the ability to modify these commons-cli properties in
CliBuilder.

Would it be possible to have another 2.5-rc release with the above change
and see what the community feedback is before we decide to revert the
CliBuilder delegation to point to the commons-cli implementation?

Marking the delegation version class as deprecated is probably a good idea
regardless of where it points to.

Remko


On Tue, May 8, 2018 at 3:19 Paul King  wrote:

>
> Both CliBuilder implementations are there via their full package names, so
> encouraging people to use the non-delegated implementation of their choice
> is a good option. They will need to get used to such changes in Groovy 3
> anyway.
>
> For Groovy 3, we might have a way for the compiler to translate from the
> existing package names to the new ones brought about by JDK9 modules, in
> which case we'd do that for CliBuilder and we'd want to point it to the
> picocli package name by then (though if we do the change below we perhaps
> wouldn't include CliBuilder in the translations list).
>
> For 2.5, we don't have the package translation in place and don't intend
> to. Because of that, the point of the delegation version is to aid in
> migration.
> Maybe it was too big a jump to try to delegate to the Picocli delegation
> in 2.5. If we find too many problems I think I should revert that change
> and delegate to the commons cli implementation instead but mark the whole
> delegation version class as deprecated.
>
> Let me know what people think.
>
> Cheers, Paul.
>
>
> On Mon, May 7, 2018 at 3:45 PM, Keegan Witt  wrote:
>
>> I'll take a look.  I'll also see if there are other places that can break.
>>
>> If there are several ways it can break, then maybe we should not use a
>> delegate to picocli and instead have folks switch the CliBuilder instance
>> they instantiate.
>>
>> -Keegan
>>
>> On Sun, May 6, 2018, 7:56 PM Remko Popma  wrote:
>>
>>> I think I found a way to fix this.
>>> See https://github.com/apache/groovy/pull/696
>>> This PR adds CliBuilder.setParser and CliBuilder.setFormatter methods
>>> that ignore the specified value and print a warning to stderr.
>>>
>>> On Sun, May 6, 2018 at 9:14 PM, Remko Popma 
>>> wrote:
>>>
 In 2.5.0-rc-2, groovy.util.CliBuilder delegates to
 groovy.cli.picocli.CliBuilder. The error is that the `parser` property of
 this class is no longer writable.

 You can resolve this with 2.5.0-rc-2 by either not setting the `parser`
 property in the CliBuilder constructor or using the
 groovy.cli.commons.CliBuilder instead.

 On the Groovy side I’m not sure what the best way is to make the
 transition easier.  The picocli version of CliBuilder can not make use of
 the Commons-CLI parser class.  We could modify CliBuilder to silently
 ignore the specified parser.  (We’d have to rename the picocli ParserSpec
 `parser` property in CliBuilder to something else.)

 Thoughts?


 On Sun, May 6, 2018 at 20:35 Keegan Witt  wrote:

> FYI 2.5.0-rc-2 breaks Gant.  Specifically, it's caused by changing
> groovy.util.CliBuilder to use Picocli
>
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:114)
> at
> org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:136)
> Caused by: groovy.lang.ReadOnlyPropertyException: Cannot set readonly
> property: parser for class: groovy.util.CliBuilder
> at
> groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:2746)
> at
> groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:3782)
> at
> groovy.lang.MetaClassImpl.setProperties(MetaClassImpl.java:1759)
> at
> org.codehaus.groovy.runtime.callsite.ConstructorSite$NoParamSite.callConstructor(ConstructorSite.java:125)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
>

Re: [VOTE] Support Java-like array

[John Wagenleitner]

+1

Originally was going to vote 0, but had more time to devote to looking over
the proposed PR/provisos and to consider the possible downsides.

On Mon, May 7, 2018 at 12:21 PM, Paul King  wrote:

> I would like to see some more PMC votes for this proposal.
>
> On the one hand we don't like changes that aren't vetted enough, yet here
> is a proposed change that:
> * is fairly comprehensive (just lacking some doco which I have already
> identified)
> * closes some gaps in one of Groovy's design goals of making it easy to
> bring Java code to Groovy
> * has sought feedback from dev and user communities (and seems to have
> strong support from our user base)
>
> And yet, I am the only one from the PMC who has voted. I don't really care
> if the votes
> are critical and provide a good reason but at least then it shows respect
> for the time and
> energy put in to preparing a considered proposal and requesting formal
> feedback.
> I know everyone is super busy but we just aren't a big enough PMC right
> now for
> everyone to sit on the fence for proposals like this.
>
> While I don't think we need to mirror everything in Java and I don't
> personally think I will
> use this feature often in my own code, I can certainly see how new users
> to Groovy would
> find it useful and so it seems like an overall win from my point of view.
> Zero-learning curve
> from Java is one of the attractions of Groovy when marketing the language.
> This seems to
> offer a bit of an improvement in that space with low investment and low
> risk.
>
> If others can see serious flaws though, it would be good to provide the
> feedback so Daniel
> can make some progress. Or if someone can see better bang-for-buck changes
> that we
> should be making from a marketing of the language perspective, it would be
> good to pass
> those insights on so Daniel and other contributors can make best use of
> their time.
>
>
> Cheers, Paul.
>
>
> On Fri, May 4, 2018 at 11:31 PM, Paul King  wrote:
>
>> I would keep discussions about warnings in a separate thread so as not to
>> derail the main topic here. If they were already widely used, it would be
>> fine to indicate that we should just add another one. But that isn't the
>> case and we'd need many discussions to do the topic justice.
>>
>> Cheers, Paul.
>>
>> On Fri, May 4, 2018 at 11:04 PM, mg  wrote:
>>
>>> +1 with all that Paul says. Plus, we should support emitting a "Java
>>> compatibility / non-idiomatic-Groovy" warning here, to avoid people using
>>> this "for Java compatibility / quick/easy copy & paste porting of Java
>>> code"-only syntax when writing actual Groovy code (surprisingly not all
>>> developers read the complete documentation of a language, before they start
>>> using it, especially for something as base line as literal array syntax :-)
>>> ).
>>>
>>> With regards to Jochen's critique of warnings in general: I absolutely
>>> agree that too many / too picky warnings are bad. But obviously we cannot
>>> use an error here instead, so if we want to keep this syntax in the corner
>>> it belongs, warning about its use looks like the only option that would
>>> consistently work in practice to me...
>>> (same as potentially for Java lambda syntax, depending on whether one
>>> will be able to use 100% equivalent & concise Groovy closure syntax here
>>> instead).
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>  Ursprüngliche Nachricht 
>>> Von: "Daniel.Sun" 
>>> Datum: 04.05.18 03:38 (GMT+01:00)
>>> An: d...@groovy.incubator.apache.org
>>> Betreff: [VOTE] Support Java-like array
>>>
>>> Dear development community,
>>>
>>>  In order to improve Groovy's compatibility with Java(Copy & Paste)
>>> and
>>> make Groovy more friendly to Java developers[1], I propose to support
>>> Java-like array[2][3] and start the VOTE thread for supporting Java-like
>>> array.
>>>
>>>  Please vote on supporting Java-like array since Apache Groovy 3.0.0.
>>>
>>>  Here are the poll results from twitter and user mailing list for
>>> your
>>> reference:
>>>
>>> Sum up the poll results
>>> 24 votes in total(including my +1)
>>> 15 +1 (62.5%)
>>> 9 0 (37.5%)
>>> 0-1 (  0.0%)
>>>
>>> Twitter[4]
>>> 19 votes in total(not including my +1)
>>> 58% +1,
>>> 42%   0,
>>> 0%   -1
>>>
>>> User mailing list(
>>> http://groovy.329449.n5.nabble.com/Poll-About-supporting-Jav
>>> a-like-array-tt5749923.html
>>> )
>>> 4 votes in total(not including my +1)
>>> 3  +1,
>>> 10,
>>> 0   -1
>>>
>>> The vote is open for the next 72 hours and passes if a majority of at
>>> least
>>> three +1 PMC votes are cast.
>>>
>>> [ ] +1 Support Java-like array
>>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>>> [ ] -1 Do not support Java-like array because...
>>>
>>> Here is my vote:
>>>
>>> +1
>>>
>>> Cheers,
>>> Daniel.Sun
>>> [1] http://groovy-lang.org/differences.html
>>> [2] 

Re: What the... static compile by default

[MG]

On 07.05.2018 17:54, Cédric Champeau wrote:

I'd typically very much prefer a custom file extension for example.


That would be my preferred way to give anyone a simple mean to choose 
static compilation as the default for a Groovy file. Afair the counter 
argument was, that Groovy compiles any file with any extension in 
dynamic mode by default, so this might be a breaking change if someone 
has used the picked extension for his files. Groovy 3.0 might be the 
right spot to introduce something like this, since there will be 
breaking changes anyway...


That said, since I'm not contributing code anymore (my last 
contribution was rewriting most of the build, which I hope was helpful),


Any improvement/speedup of the Gradle build was _definitely_ appreciated :-)


I'm happy to step down and let you work as you wish.


This is tricky: One cannot agree with just any direction someone who 
invests the time to advance Groovy wants to take it too, that would be 
taking Doocracy too far, imho, and might lead to a Groovy which is much 
worse than it could be.
In this particular case I am torn: I think we could definitely live with 
the system property, I don't feel there is a large probability that it 
will break anything. On the other hand, using the existing mechanism, or 
introducing a static compilation source file extension, or a compiler 
switch seem to me to be the better choices - but maybe Daniel can 
explain why he went with the property approach ?-)


Cheers,
mg

Re: [DRAFT] Proposed board report for Apache Groovy for May 2018

[MG]

If I would venture a guess, and gauging from articles in magazines, I 
would say the upcoming Groovy 3.0 major release creates quite some buzz...

Cheers,
mg


On 07.05.2018 15:34, Daniel.Sun wrote:

Yep. It is a great news.
As you all know, Groovy is lack of marketing, so I wonder why Groovy
adoption grows so much.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [VOTE] Support Java-like array

[MG]

On 07.05.2018 22:03, Guillaume Laforge wrote:

I haven't voted as I'm not a big fan of adding this syntax construct.

My feeling is that we shouldn't necessarily try to become a pure 
Java-superset, and it shouldn't be a goal to try more and more to 
close that gap.


Being able to write Java constructs in Groovy and incorporating the 
improvements Groovy has to offer one after another was a major factor 
for me, and it continues to be very helpful when introducing new 
colleaugues to Groovy. If they know Java (and who does not, nowadays ?), 
you can tell them: Just use what you know and - oh yea, do a search and 
replace and remove all the semicolons at the end of each line, and you 
can use a multiline String with embedded variables here, you might wanna 
use a list literal there - and just say file.text = list.join('\n') to 
write the result to a file, ...


There are some confusing cases where (single element) array 
initializers can be confounded with closures.


Also, I tend to prefer square brackets over curlies, but that's 
certainly a question of taste.


Agree with both points. I still think the plus outhweighs the minus - 
see above and below.




The other thing that slightly annoys me is that we're adding 
additional syntax for the same thing: array initializers, but look at 
how we added lambda notation.
How will we explain users why we have two syntaxes for the same thing? 
Or when/why they should use one over the other?


Hence my suggestion to issue a "non-canonical Groovy / Java construct"- 
warning in these cases - which everyone seems to confuse with some sort 
of coding style warning, which to me it is clearly not: One just has to 
ask oneself, whether anyone would have even considered voting for "...a 
brand new alias for def: var !", or "...a way to write array literals, 
so the look like closures: The amazing curly braces array literals 
!" (spoken with the voice of the boss from "IT Crowd", season 1 ;-) ).


(I understand that we currently don't have warnings in Groovy, but 
seriously, how hard can it be to add errors which do not make the build 
fail ?-)  )


Cheers,
mg

Re: [VOTE] Support Java-like array

[Guillaume Laforge]

I haven't voted as I'm not a big fan of adding this syntax construct.

My feeling is that we shouldn't necessarily try to become a pure
Java-superset, and it shouldn't be a goal to try more and more to close
that gap.
There are some confusing cases where (single element) array initializers
can be confounded with closures.

Also, I tend to prefer square brackets over curlies, but that's certainly a
question of taste.

The other thing that slightly annoys me is that we're adding additional
syntax for the same thing: array initializers, but look at how we added
lambda notation.
How will we explain users why we have two syntaxes for the same thing? Or
when/why they should use one over the other?

I guess with 15 years involved in various ways with Groovy, I'm also
becoming more conservative with changes, and I fear that we might be making
Groovy more / too complicated.

So I will vote, but only with +0.

Guillaume



On Mon, May 7, 2018 at 9:21 PM, Paul King  wrote:

> I would like to see some more PMC votes for this proposal.
>
> On the one hand we don't like changes that aren't vetted enough, yet here
> is a proposed change that:
> * is fairly comprehensive (just lacking some doco which I have already
> identified)
> * closes some gaps in one of Groovy's design goals of making it easy to
> bring Java code to Groovy
> * has sought feedback from dev and user communities (and seems to have
> strong support from our user base)
>
> And yet, I am the only one from the PMC who has voted. I don't really care
> if the votes
> are critical and provide a good reason but at least then it shows respect
> for the time and
> energy put in to preparing a considered proposal and requesting formal
> feedback.
> I know everyone is super busy but we just aren't a big enough PMC right
> now for
> everyone to sit on the fence for proposals like this.
>
> While I don't think we need to mirror everything in Java and I don't
> personally think I will
> use this feature often in my own code, I can certainly see how new users
> to Groovy would
> find it useful and so it seems like an overall win from my point of view.
> Zero-learning curve
> from Java is one of the attractions of Groovy when marketing the language.
> This seems to
> offer a bit of an improvement in that space with low investment and low
> risk.
>
> If others can see serious flaws though, it would be good to provide the
> feedback so Daniel
> can make some progress. Or if someone can see better bang-for-buck changes
> that we
> should be making from a marketing of the language perspective, it would be
> good to pass
> those insights on so Daniel and other contributors can make best use of
> their time.
>
>
> Cheers, Paul.
>
>
> On Fri, May 4, 2018 at 11:31 PM, Paul King  wrote:
>
>> I would keep discussions about warnings in a separate thread so as not to
>> derail the main topic here. If they were already widely used, it would be
>> fine to indicate that we should just add another one. But that isn't the
>> case and we'd need many discussions to do the topic justice.
>>
>> Cheers, Paul.
>>
>> On Fri, May 4, 2018 at 11:04 PM, mg  wrote:
>>
>>> +1 with all that Paul says. Plus, we should support emitting a "Java
>>> compatibility / non-idiomatic-Groovy" warning here, to avoid people using
>>> this "for Java compatibility / quick/easy copy & paste porting of Java
>>> code"-only syntax when writing actual Groovy code (surprisingly not all
>>> developers read the complete documentation of a language, before they start
>>> using it, especially for something as base line as literal array syntax :-)
>>> ).
>>>
>>> With regards to Jochen's critique of warnings in general: I absolutely
>>> agree that too many / too picky warnings are bad. But obviously we cannot
>>> use an error here instead, so if we want to keep this syntax in the corner
>>> it belongs, warning about its use looks like the only option that would
>>> consistently work in practice to me...
>>> (same as potentially for Java lambda syntax, depending on whether one
>>> will be able to use 100% equivalent & concise Groovy closure syntax here
>>> instead).
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>  Ursprüngliche Nachricht 
>>> Von: "Daniel.Sun" 
>>> Datum: 04.05.18 03:38 (GMT+01:00)
>>> An: d...@groovy.incubator.apache.org
>>> Betreff: [VOTE] Support Java-like array
>>>
>>> Dear development community,
>>>
>>>  In order to improve Groovy's compatibility with Java(Copy & Paste)
>>> and
>>> make Groovy more friendly to Java developers[1], I propose to support
>>> Java-like array[2][3] and start the VOTE thread for supporting Java-like
>>> array.
>>>
>>>  Please vote on supporting Java-like array since Apache Groovy 3.0.0.
>>>
>>>  Here are the poll results from twitter and user mailing list for
>>> your
>>> reference:
>>>
>>> Sum up the poll results
>>> 24 votes in total(including my +1)
>>> 15 +1 (62.5%)
>>> 9 0 

Re: [VOTE] Support Java-like array

[Paul King]

I would like to see some more PMC votes for this proposal.

On the one hand we don't like changes that aren't vetted enough, yet here
is a proposed change that:
* is fairly comprehensive (just lacking some doco which I have already
identified)
* closes some gaps in one of Groovy's design goals of making it easy to
bring Java code to Groovy
* has sought feedback from dev and user communities (and seems to have
strong support from our user base)

And yet, I am the only one from the PMC who has voted. I don't really care
if the votes
are critical and provide a good reason but at least then it shows respect
for the time and
energy put in to preparing a considered proposal and requesting formal
feedback.
I know everyone is super busy but we just aren't a big enough PMC right now
for
everyone to sit on the fence for proposals like this.

While I don't think we need to mirror everything in Java and I don't
personally think I will
use this feature often in my own code, I can certainly see how new users to
Groovy would
find it useful and so it seems like an overall win from my point of view.
Zero-learning curve
from Java is one of the attractions of Groovy when marketing the language.
This seems to
offer a bit of an improvement in that space with low investment and low
risk.

If others can see serious flaws though, it would be good to provide the
feedback so Daniel
can make some progress. Or if someone can see better bang-for-buck changes
that we
should be making from a marketing of the language perspective, it would be
good to pass
those insights on so Daniel and other contributors can make best use of
their time.


Cheers, Paul.


On Fri, May 4, 2018 at 11:31 PM, Paul King  wrote:

> I would keep discussions about warnings in a separate thread so as not to
> derail the main topic here. If they were already widely used, it would be
> fine to indicate that we should just add another one. But that isn't the
> case and we'd need many discussions to do the topic justice.
>
> Cheers, Paul.
>
> On Fri, May 4, 2018 at 11:04 PM, mg  wrote:
>
>> +1 with all that Paul says. Plus, we should support emitting a "Java
>> compatibility / non-idiomatic-Groovy" warning here, to avoid people using
>> this "for Java compatibility / quick/easy copy & paste porting of Java
>> code"-only syntax when writing actual Groovy code (surprisingly not all
>> developers read the complete documentation of a language, before they start
>> using it, especially for something as base line as literal array syntax :-)
>> ).
>>
>> With regards to Jochen's critique of warnings in general: I absolutely
>> agree that too many / too picky warnings are bad. But obviously we cannot
>> use an error here instead, so if we want to keep this syntax in the corner
>> it belongs, warning about its use looks like the only option that would
>> consistently work in practice to me...
>> (same as potentially for Java lambda syntax, depending on whether one
>> will be able to use 100% equivalent & concise Groovy closure syntax here
>> instead).
>>
>> Cheers,
>> mg
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: "Daniel.Sun" 
>> Datum: 04.05.18 03:38 (GMT+01:00)
>> An: d...@groovy.incubator.apache.org
>> Betreff: [VOTE] Support Java-like array
>>
>> Dear development community,
>>
>>  In order to improve Groovy's compatibility with Java(Copy & Paste)
>> and
>> make Groovy more friendly to Java developers[1], I propose to support
>> Java-like array[2][3] and start the VOTE thread for supporting Java-like
>> array.
>>
>>  Please vote on supporting Java-like array since Apache Groovy 3.0.0.
>>
>>  Here are the poll results from twitter and user mailing list for your
>> reference:
>>
>> Sum up the poll results
>> 24 votes in total(including my +1)
>> 15 +1 (62.5%)
>> 9 0 (37.5%)
>> 0-1 (  0.0%)
>>
>> Twitter[4]
>> 19 votes in total(not including my +1)
>> 58% +1,
>> 42%   0,
>> 0%   -1
>>
>> User mailing list(
>> http://groovy.329449.n5.nabble.com/Poll-About-supporting-
>> Java-like-array-tt5749923.html
>> )
>> 4 votes in total(not including my +1)
>> 3  +1,
>> 10,
>> 0   -1
>>
>> The vote is open for the next 72 hours and passes if a majority of at
>> least
>> three +1 PMC votes are cast.
>>
>> [ ] +1 Support Java-like array
>> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not support Java-like array because...
>>
>> Here is my vote:
>>
>> +1
>>
>> Cheers,
>> Daniel.Sun
>> [1] http://groovy-lang.org/differences.html
>> [2] https://github.com/apache/groovy/pull/691
>> [3] https://issues.apache.org/jira/browse/GROOVY-8561
>> [4] https://twitter.com/daniel_sun/status/990544485196091395
>>
>>
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>

Re: What the... static compile by default

[Paul King]

Hi Daniel,

I am very keen for you to maintain your involvement in Groovy. There is no
way we'd have Groovy 3 in it's current form without your involvement. I
also find your enthusiasm contagious and a welcome addition to the
community.

Cheers, Paul.

>> On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:
> >>>
> >>> Hi Cédric,
> >>>
> >>>   Feel free to remove any code.
> >>>   To be honest, I am really tired.
> >>>   Bye Groovy community.
> >>>
> >>> Cheers,
> >>> Daniel.Sun
>

Re: What the... static compile by default

[Graeme Rocher]

Hi Cedric,

I don't think anybody wants anybody to step down (whether that be you,
Daniel or whoever) and you make valid points about processes that
could be improved. I would however encourage you to re-read your
original email to understand how it may impact others. Maybe adjust
the tone of your emails since this is not the first email of that
nature. Starting off being the bad cop and usage of phrases like "when
the heck" it came across as aggressive and I can understand why Daniel
and possibly others would feel discouraged. I know however your
intention is good and maybe it is a language thing. We all want the
best for Groovy at the end of the day.

Cheers

On Mon, May 7, 2018 at 5:54 PM, Cédric Champeau
 wrote:
> Hi Daniel and sorry you are "tired". Maybe the tone I used was
> inappropriate?, but it wasn't directed at you personally. I'm quite
> surprised to see some things like that happening on master without any
> discussion on the MLs. Maybe that's because I expect too much from the
> developers of Groovy, but I strongly think we owe better to the community,
> and in particular code quality. In that area, we don't have _any_ peer
> review. Everybody works on master, and I think that's a bad idea. Things
> like this happen, but we have to realize that Groovy is used by tens of
> thousands of developers, so any choice we make has consequences. So, if we
> had peer reviews, questions like this wouldn't happen. Should you want to
> introduce a feature, it wouldn't go to master without a review from another
> committer/PMC. Same for Paul, and same for me. I think it's too easy to push
> to master today, and this bites us.
>
> So to come back to the original topic of this thread, I never saw that
> ticket, and, for one, don't read every ticket out there, I mostly have time
> to follow discussions on the MLs. So I can react when I see something that
> looks wrong to me. Here, I don't have the impression that the ticket even
> comes to any conclusion, it just "happened". I still think the approach is
> incorrect, I'd typically very much prefer a custom file extension for
> example. And if it's just for internal testing, the compiler configuration
> already has everything we need without having to rely on a system property.
> We have to realize that adding a property without testing it in combination
> with other flags is a problem too.
>
> That said, since I'm not contributing code anymore (my last contribution was
> rewriting most of the build, which I hope was helpful), I'm happy to step
> down and let you work as you wish. I mostly want to make sure Groovy goes in
> the right direction. If I'm a blocker, I have no problem with that.
>
> 2018-05-07 17:40 GMT+02:00 Jeff Scott Brown :
>>
>>
>>
>> On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:
>>>
>>> Hi Cédric,
>>>
>>>   Feel free to remove any code.
>>>   To be honest, I am really tired.
>>>   Bye Groovy community.
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>> }
>>
>> Daniel,
>>
>> Please reconsider.  I think the tone at the beginning of this thread was
>> unfortunate and I expect that has contributed to your frustration.
>>
>> Your contributions are very much appreciated by the community and you
>> should be proud of the work you are doing with Groovy.  It would be a real
>> shame to lose your enthusiasm and contributions to this great language and
>> great ecosystem.  I mean that sincerely.
>>
>> Let me know whatever I can do to help.
>>
>> Thanks for all of your great work.  Well done sir!
>>
>>
>>
>>
>> JSB
>> --
>> Jeff Scott Brown
>> OCI Partner and Principal Software Engineer
>> OCI Grails Practice Lead
>>
>> Autism Strikes 1 in 166
>> Find The Cause ~ Find The Cure
>> http://www.autismspeaks.org/
>
>



-- 
Graeme Rocher

Re: What the... static compile by default

[mg]

Hi Daniel,
is that a quote of someone who has left the project at some point or you 
yourself talking ? If it is you: I get your frustation and - don't go :-)
Technically, would a "compile static" compiler switch be a compromise, or has 
this alteady been ruled out (if the switch had the lowest priority, it should 
not collide with all the existing ways to apply @CompileStatic to Groovy code) ?
Cheers,mg
 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 07.05.18  16:59  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: What the... static compile by default 
Hi Cédric,

  Feel free to remove any code.
  To be honest, I am really tired. 
  Bye Groovy community.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: What the... static compile by default

[mg]

Hi Daniel,
is that a quote of someone who has left the project at some point or you 
yourself talking ? If it is you: I get your frustation and - don't go :-)
Technically, would a "compile static" compiler switch be a compromise, or has 
this alteady been ruled out (if the switch had the lowest priority, it should 
not collide with all the existing ways to apply @CompileStatic to Groovy code) ?
Cheers,mg
 Ursprüngliche Nachricht Von: "Daniel.Sun"  
Datum: 07.05.18  16:59  (GMT+01:00) An: d...@groovy.incubator.apache.org 
Betreff: Re: What the... static compile by default 
Hi Cédric,

  Feel free to remove any code.
  To be honest, I am really tired. 
  Bye Groovy community.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: What the... static compile by default

[Sergio del Amo Caballero]

Daniel, please note your contribution to Groovy has not gone without
notice. Personally, I am very grateful for the work you have done.
Moreover, I am grateful for the enthusiasm towards twitter you have shown
in every email and tweet. It has been awesome and contagious.  I hope you
stay in the Groovy Community because without any doubt you make it better.

Sergio del Amo

On 7 May 2018 at 16:59, Daniel.Sun  wrote:

> Hi Cédric,
>
>   Feel free to remove any code.
>   To be honest, I am really tired.
>   Bye Groovy community.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>



-- 
Sergio del Amo Caballero
http://softamo.com
http://sergiodelamo.es
http://www.sergiodelamo.com
Sigueme en twitter: http://twitter.com/sdelamo
Hazte fan en facebook: http://www.facebook.com/sergiodelamocaballero
email: sergio.del...@softamo.com
Tfno: +34 949 31 48 86 / +34 630442973

Re: What the... static compile by default

[Cédric Champeau]

Hi Daniel and sorry you are "tired". Maybe the tone I used was
inappropriate?, but it wasn't directed at you personally. I'm quite
surprised to see some things like that happening on master without any
discussion on the MLs. Maybe that's because I expect too much from the
developers of Groovy, but I strongly think we owe better to the community,
and in particular code quality. In that area, we don't have _any_ peer
review. Everybody works on master, and I think that's a bad idea. Things
like this happen, but we have to realize that Groovy is used by tens of
thousands of developers, so any choice we make has consequences. So, if we
had peer reviews, questions like this wouldn't happen. Should you want to
introduce a feature, it wouldn't go to master without a review from another
committer/PMC. Same for Paul, and same for me. I think it's too easy to
push to master today, and this bites us.

So to come back to the original topic of this thread, I never saw that
ticket, and, for one, don't read every ticket out there, I mostly have time
to follow discussions on the MLs. So I can react when I see something that
looks wrong to me. Here, I don't have the impression that the ticket even
comes to any conclusion, it just "happened". I still think the approach is
incorrect, I'd typically very much prefer a custom file extension for
example. And if it's just for internal testing, the compiler configuration
already has everything we need without having to rely on a system property.
We have to realize that adding a property without testing it in combination
with other flags is a problem too.

That said, since I'm not contributing code anymore (my last contribution
was rewriting most of the build, which I hope was helpful), I'm happy to
step down and let you work as you wish. I mostly want to make sure Groovy
goes in the right direction. If I'm a blocker, I have no problem with that.

2018-05-07 17:40 GMT+02:00 Jeff Scott Brown :

>
>
> On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:
>
>> Hi Cédric,
>>
>>   Feel free to remove any code.
>>   To be honest, I am really tired.
>>   Bye Groovy community.
>>
>> Cheers,
>> Daniel.Sun
>>
>> }
>
> Daniel,
>
> Please reconsider.  I think the tone at the beginning of this thread was
> unfortunate and I expect that has contributed to your frustration.
>
> Your contributions are very much appreciated by the community and you
> should be proud of the work you are doing with Groovy.  It would be a real
> shame to lose your enthusiasm and contributions to this great language and
> great ecosystem.  I mean that sincerely.
>
> Let me know whatever I can do to help.
>
> Thanks for all of your great work.  Well done sir!
>
>
>
>
> JSB
> --
> Jeff Scott Brown
> OCI Partner and Principal Software Engineer
> OCI Grails Practice Lead
>
> Autism Strikes 1 in 166
> Find The Cause ~ Find The Cure
> http://www.autismspeaks.org/
>

Re: What the... static compile by default

[Jeff Scott Brown]

On 2018/05/07 14:59:09, "Daniel.Sun"  wrote:

Hi Cédric,

  Feel free to remove any code.
  To be honest, I am really tired.
  Bye Groovy community.

Cheers,
Daniel.Sun


}

Daniel,

Please reconsider.  I think the tone at the beginning of this thread was 
unfortunate and I expect that has contributed to your frustration.


Your contributions are very much appreciated by the community and you 
should be proud of the work you are doing with Groovy.  It would be a 
real shame to lose your enthusiasm and contributions to this great 
language and great ecosystem.  I mean that sincerely.


Let me know whatever I can do to help.

Thanks for all of your great work.  Well done sir!




JSB
--
Jeff Scott Brown
OCI Partner and Principal Software Engineer
OCI Grails Practice Lead

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

Re: What the... static compile by default

[Graeme Rocher]

I hope you don't get discouraged Daniel, you are doing amazing work in
the community and currently you and Paul are the main contributors /
drivers of the project.

Cerdic - whilst I am sure you mean well I gotta say I disagree with
your approach to raising issues on the mailing list. There was already
a JIRA comments thread on the issue (GROOVY-8543) debating the value
of the system property and it would likely have been removed without
all this fuss, what is the point of openly discouraging folks who are
actually making a contribution to Groovy?

My 2 cents.


On Mon, May 7, 2018 at 4:59 PM, Daniel.Sun  wrote:
> Hi Cédric,
>
>   Feel free to remove any code.
>   To be honest, I am really tired.
>   Bye Groovy community.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html



-- 
Graeme Rocher

Re: What the... static compile by default

[Daniel.Sun]

Hi Cédric,

  Feel free to remove any code.
  To be honest, I am really tired. 
  Bye Groovy community.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: What the... static compile by default

[Thibault Kruse]

Git blame seems to indicate April 13th 2018, and it seems to be
related to this ticket:
https://issues.apache.org/jira/browse/GROOVY-8543

On Mon, May 7, 2018 at 11:05 PM, Cédric Champeau
 wrote:
> Hi folks,
>
> Sorry to be the bad cop again, but when the heck did this land into core:
>
> https://github.com/apache/groovy/blob/5443e87882f9b88169876f6d043ed54b5ae9023b/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L943-L988
>
> As much as I love static compilation, this should never have landed into
> master, at least not without an agreement. I strongly believe enabling
> static compilation by default using a system property is a bad thing. We
> already have an official, supported mechanism for this, which is documented
> [1], so adding one silently is not very nice. I reckon lots of users want to
> have static compilation by default, but I don't think a system property is
> the way to go.
>
> [1]
> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

What the... static compile by default

[Cédric Champeau]

Hi folks,

Sorry to be the bad cop again, but when the heck did this land into core:

https://github.com/apache/groovy/blob/5443e87882f9b88169876f6d043ed54b5ae9023b/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L943-L988

As much as I love static compilation, this should never have landed into
master, at least not without an agreement. I strongly believe enabling
static compilation by default using a system property is a bad thing. We
already have an official, supported mechanism for this, which is documented
[1], so adding one silently is not very nice. I reckon lots of users want
to have static compilation by default, but I don't think a system property
is the way to go.

[1]
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

Re: [DRAFT] Proposed board report for Apache Groovy for May 2018

[Daniel.Sun]

Yep. It is a great news.
As you all know, Groovy is lack of marketing, so I wonder why Groovy
adoption grows so much.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: [DRAFT] Proposed board report for Apache Groovy for May 2018

[mg]

@Groovy downloads x2: Great news! :-)
 Ursprüngliche Nachricht Von: Guillaume Laforge 
 Datum: 07.05.18  11:39  (GMT+01:00) An: 
dev@groovy.apache.org, Paul King  Betreff: Re: [DRAFT] 
Proposed board report for Apache Groovy for May 2018 
Hi Paul,
I've submitted the report with the addition of the download numbers.
 - Over the previous quarter, Apache Groovy has been downloaded 19 million   
times. Twice as much in Q1'18 as the same period the previous year.
Download figures keep growing :-)
Guillaume
On Sun, May 6, 2018 at 5:05 AM, Paul King  wrote:

In case Guillaume delegates the board report to me, I thought I would get 
inearly and produce a draft in case anyone else has anything to add. It is 
duein a few days time.
Guillaume, feel free to send as is or add in more info if you want or 
receivefurther feedback. It DOESN'T have download numbers in as yet. I jump on 
aplane tonight but I can progress further if need be in a couple of days time.
Cheers, Paul.



//

## Description: 


Apache Groovy is a multi-faceted programming language for the Java 
platform.Groovy is a powerful, optionally typed and dynamic language, with 
static-typing and static compilation capabilities, aimed at multiplying 
developers’productivity thanks to a concise, familiar and easy to learn syntax. 
Itintegrates smoothly with any Java program, and immediately delivers to 
yourapplication powerful features, including scripting capabilities, 
Domain-Specific Language authoring, first class functional programming support 
and runtime and compile-time meta-programming.   ## Issues: 
There are no new issues requiring board attention at this time.Outstanding 
issues: - The final steps to completing the website migration are still 
outstanding.   A new issue has been raised wrt bad formatting on the https 
version of the   site due to the current status, so there will be increased 
pressure on us to   complete this task. - The community is still keen on some 
kind of Groovy Champions scheme.   We have passed on the information around 
Apache requirements for such   a scheme was it to move forward. No further 
discussions have taken place.   ## Activity:
 - This quarter, 349 commits were contributed from 18 contributors   including 
11 non-committer contributors (10 new).   ## Health report:


 - Our release train velocity has been maintained, and there seems to be a   
healthy level of discussion about project direction on the mailing lists.

   ## PMC changes:     - Currently 10 PMC members.  - No new PMC members added 
in the last 3 months  - Last PMC addition was John Wagenleitner on Sun Apr 02 
2017    ## Committer base changes:     - Currently 18 committers.  - No new 
committers added in the last 3 months  - Last committer addition was Sergei 
Egorov at Thu Dec 08 2016    ## Releases:     - 2.4.14 was released on Fri Mar 
02 2018  - 2.4.15 was released on Tue Mar 27 2018  - 2.5.0-beta-3 was released 
on Fri Feb 23 2018  - 2.5.0-rc-1 was released on Mon Apr 09 2018  - 
2.6.0-alpha-3 was released on Tue Mar 06 2018  - 3.0.0-alpha-2 was released on 
Tue Apr 17 2018    ## Mailing list activity:     - Slight increase in 
subscribers over the period otherwise nothing to report   ## JIRA activity:     
- 101 JIRA tickets created in the last 3 months  - 88 JIRA tickets 
closed/resolved in the last 3 months




-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-PresidentDeveloper Advocate @ Google Cloud 
Platform

Blog: http://glaforge.appspot.com/Twitter: @glaforge

Re: [DRAFT] Proposed board report for Apache Groovy for May 2018

[Jochen Theodorou]

thanks you two for always taking care of these things

Am 07.05.2018 um 11:39 schrieb Guillaume Laforge:

Hi Paul,

I've submitted the report with the addition of the download numbers.

  - Over the previous quarter, Apache Groovy has been downloaded 19 million
    times. Twice as much in Q1'18 as the same period the previous year.

Download figures keep growing :-)

Guillaume

On Sun, May 6, 2018 at 5:05 AM, Paul King > wrote:



In case Guillaume delegates the board report to me, I thought I
would get in
early and produce a draft in case anyone else has anything to add.
It is due
in a few days time.

Guillaume, feel free to send as is or add in more info if you want
or receive
further feedback. It DOESN'T have download numbers in as yet. I jump
on a
plane tonight but I can progress further if need be in a couple of
days time.

Cheers, Paul.

//


## Description:

Apache Groovy is a multi-faceted programming language for the Java
platform.
Groovy is a powerful, optionally typed and dynamic language, with
static-
typing and static compilation capabilities, aimed at multiplying
developers’
productivity thanks to a concise, familiar and easy to learn syntax. It
integrates smoothly with any Java program, and immediately delivers
to your
application powerful features, including scripting capabilities, Domain-
Specific Language authoring, first class functional programming support
and runtime and compile-time meta-programming.
## Issues:

There are no new issues requiring board attention at this time.
Outstanding issues:
  - The final steps to completing the website migration are still
outstanding.
    A new issue has been raised wrt bad formatting on the https
version of the
    site due to the current status, so there will be increased
pressure on us to
    complete this task.
  - The community is still keen on some kind of Groovy Champions scheme.
    We have passed on the information around Apache requirements for
such
    a scheme was it to move forward. No further discussions have
taken place.
## Activity:

  - This quarter, 349 commits were contributed from 18 contributors
    including 11 non-committer contributors (10 new).
## Health report:

  - Our release train velocity has been maintained, and there seems
to be a
    healthy level of discussion about project direction on the
mailing lists.
## PMC changes:
  - Currently 10 PMC members.
  - No new PMC members added in the last 3 months
  - Last PMC addition was John Wagenleitner on Sun Apr 02 2017
## Committer base changes:
  - Currently 18 committers.
  - No new committers added in the last 3 months
  - Last committer addition was Sergei Egorov at Thu Dec 08 2016
## Releases:
  - 2.4.14 was released on Fri Mar 02 2018
  - 2.4.15 was released on Tue Mar 27 2018
  - 2.5.0-beta-3 was released on Fri Feb 23 2018
  - 2.5.0-rc-1 was released on Mon Apr 09 2018
  - 2.6.0-alpha-3 was released on Tue Mar 06 2018
  - 3.0.0-alpha-2 was released on Tue Apr 17 2018
## Mailing list activity:
  - Slight increase in subscribers over the period otherwise nothing
to report
## JIRA activity:
  - 101 JIRA tickets created in the last 3 months
  - 88 JIRA tickets closed/resolved in the last 3 months




--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Twitter: @glaforge 

Re: [DRAFT] Proposed board report for Apache Groovy for May 2018

[Guillaume Laforge]

Hi Paul,

I've submitted the report with the addition of the download numbers.

 - Over the previous quarter, Apache Groovy has been downloaded 19 million
   times. Twice as much in Q1'18 as the same period the previous year.

Download figures keep growing :-)

Guillaume

On Sun, May 6, 2018 at 5:05 AM, Paul King  wrote:

>
> In case Guillaume delegates the board report to me, I thought I would get
> in
> early and produce a draft in case anyone else has anything to add. It is
> due
> in a few days time.
>
> Guillaume, feel free to send as is or add in more info if you want or
> receive
> further feedback. It DOESN'T have download numbers in as yet. I jump on a
> plane tonight but I can progress further if need be in a couple of days
> time.
>
> Cheers, Paul.
>
> //
>
>
> ## Description:
>
> Apache Groovy is a multi-faceted programming language for the Java
> platform.
> Groovy is a powerful, optionally typed and dynamic language, with static-
> typing and static compilation capabilities, aimed at multiplying
> developers’
> productivity thanks to a concise, familiar and easy to learn syntax. It
> integrates smoothly with any Java program, and immediately delivers to your
> application powerful features, including scripting capabilities, Domain-
> Specific Language authoring, first class functional programming support
> and runtime and compile-time meta-programming.
>
> ## Issues:
>
> There are no new issues requiring board attention at this time.
> Outstanding issues:
>  - The final steps to completing the website migration are still
> outstanding.
>A new issue has been raised wrt bad formatting on the https version of
> the
>site due to the current status, so there will be increased pressure on
> us to
>complete this task.
>  - The community is still keen on some kind of Groovy Champions scheme.
>We have passed on the information around Apache requirements for such
>a scheme was it to move forward. No further discussions have taken
> place.
>
> ## Activity:
>
>  - This quarter, 349 commits were contributed from 18 contributors
>including 11 non-committer contributors (10 new).
>
> ## Health report:
>
>  - Our release train velocity has been maintained, and there seems to be a
>healthy level of discussion about project direction on the mailing
> lists.
>
> ## PMC changes:
>
>  - Currently 10 PMC members.
>  - No new PMC members added in the last 3 months
>  - Last PMC addition was John Wagenleitner on Sun Apr 02 2017
>
> ## Committer base changes:
>
>  - Currently 18 committers.
>  - No new committers added in the last 3 months
>  - Last committer addition was Sergei Egorov at Thu Dec 08 2016
>
> ## Releases:
>
>  - 2.4.14 was released on Fri Mar 02 2018
>  - 2.4.15 was released on Tue Mar 27 2018
>  - 2.5.0-beta-3 was released on Fri Feb 23 2018
>  - 2.5.0-rc-1 was released on Mon Apr 09 2018
>  - 2.6.0-alpha-3 was released on Tue Mar 06 2018
>  - 3.0.0-alpha-2 was released on Tue Apr 17 2018
>
> ## Mailing list activity:
>
>  - Slight increase in subscribers over the period otherwise nothing to
> report
>
> ## JIRA activity:
>
>  - 101 JIRA tickets created in the last 3 months
>  - 88 JIRA tickets closed/resolved in the last 3 months
>
>


-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Twitter: @glaforge