Re: groovy-all

[Cédric Champeau]

Easiest is _not_ to use groovy-all, which is really a convenience to get
_all_ Groovy modules. It's extremely unlikely you need them all, as your
message indicates (you don't need testng, but I'm pretty sure you don't
need groovy-swing either).

Le jeu. 24 oct. 2019 à 09:47,  a écrit :

> Hi,
>
> is there groovy maven dependency, that can be used in a java project
> without pulling in test ng?
>
> The test ng „gift“ is quite a nuisance, if junit tests are used. Even if
> junit is disabled for test ng, test ng still checks each and every junit
> test case (which takes roughly half a second on my box).
>
>
>
>
>
> Kind Regards,
>
> Arne
>

Re: Friends of Groovy Open Collective

[Cédric Champeau]

I realize it's still unclear to me who is going to decide about how to
spend the money. Reading the page it seems like Paul and Daniel are, which
may be seen as a conflict of interest. Would be good to clarify.

Le lun. 11 mars 2019 à 13:18, Guillaume Laforge  a
écrit :

> Just sponsored the project!
> Looking forward to seeing many contributions coming up!
>
> Guillaume
>
>
> On Thu, Mar 7, 2019 at 1:33 PM Cédric Champeau 
> wrote:
>
>> Cool, let's see how it goes!
>>
>> Le jeu. 7 mars 2019 à 13:23, Daniel Sun  a
>> écrit :
>>
>>> Hi Paul,
>>>
>>>  I'm very glad to hear the great news!
>>>
>>>  Up to now, Friends of Groovy Open Collective has received donations
>>> from(order by donation time):
>>> 1) Jorge Aguilera($10, backer)
>>> 2) GR8Conf($50)
>>> 3) Masaaki Saito($50)
>>> 4) Lemi Orhan Ergin($10)
>>> 5) Adam Davis($20)
>>> 6) Paolo Di Tommaso($50)
>>> 7) David Dawson($100, sponsor)
>>> (Note: backer donates $5+ per month, sponsor donates $100+ per month)
>>>
>>>  Thanks a lot for your contribution. I believe Groovy will be great
>>> again because of our endless effort :-)
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>>>
>>
>
> --
> Guillaume Laforge
> Apache Groovy committer
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge <http://twitter.com/glaforge>
>

Re: Friends of Groovy Open Collective

[Cédric Champeau]

Cool, let's see how it goes!

Le jeu. 7 mars 2019 à 13:23, Daniel Sun  a écrit :

> Hi Paul,
>
>  I'm very glad to hear the great news!
>
>  Up to now, Friends of Groovy Open Collective has received donations
> from(order by donation time):
> 1) Jorge Aguilera($10, backer)
> 2) GR8Conf($50)
> 3) Masaaki Saito($50)
> 4) Lemi Orhan Ergin($10)
> 5) Adam Davis($20)
> 6) Paolo Di Tommaso($50)
> 7) David Dawson($100, sponsor)
> (Note: backer donates $5+ per month, sponsor donates $100+ per month)
>
>  Thanks a lot for your contribution. I believe Groovy will be great
> again because of our endless effort :-)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: Gant is to be deleted, or will someone preserve it?

[Cédric Champeau]

An alternative is to "archive" the project in GitHub. It's going to be
read-only (see the "settings" tab).

Le sam. 2 févr. 2019 à 09:46, Russel Winder  a écrit :

> On Sat, 2019-02-02 at 09:18 +0100, Guillaume Laforge wrote:
> > Why deleting it?
> > Keep it for posterity! :-)
>
> Someone, or some people, then needs to step up and volunteer to be an
> owner of
> the Gant organisation on GitHub.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>
>

Re: @Immutable backwards compatibility

[Cédric Champeau]

The "migration" may not be painful but breaking user builds or plugins when
they upgrade Gradle is not cool. Several issues have been filed already as
I understand.

Le sam. 13 oct. 2018 à 17:41, Daniel.Sun  a écrit :

> Hi  Cédric,
>
> > However, we discovered several regressions (in @CompileStatic, in
> > covariant return type checking, ...) that may make the migration
> painful.
>   According to the changed files shown in the PR (
> https://github.com/gradle/gradle/pull/6903/files ), it seems that the
> migration is not that painful ;-)
>
>   BTW, all changes for 2.5.x pass all existing tests in Groovy project.
> If you find some breaking change, feel free to submit JIRA ticket to track.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

@Immutable backwards compatibility

[Cédric Champeau]

Hi folks,

Gradle 5 is migrating to Groovy 2.5 (yay!). However, we discovered several
regressions (in @CompileStatic, in covariant return type checking, ...)
that may make the migration painful. One of them is unexpected for our
users: the @Immutable AST transformation changed the runtime checks, so a
class compiled with 2.4 running on 2.5 would suddenly fail. An example of
such a problem has been reported at
https://github.com/ajoberstar/grgit/issues/237

Our partners at Netflix already mentioned they had to fork several plugins
to accommodate the problem. While the new checks are legit, the fact that
it's an AST xform (happening at compile time) and that the additional check
happens at runtime can be surprising.

I'm not sure if we need to change this, but having an incompatibility may
be annoying.

Re: Groovy 2.5.1 planning

[Cédric Champeau]

+1

Le mar. 3 juil. 2018 à 08:37, Paul King  a écrit :

>
> Hi everyone,
>
> Even though I still have plenty of bugs on my "would like to fix before
> next release" list,
> I'd like to release a 2.5.1 fairly soon. This is mostly to do with 2.5.0
> inadvertently breaking
> our OSGi support [1] but also based on usability feedback I have moved
> Groovy's recently
> introduced JAXB extension methods into their own optional module [2]. This
> is a breaking
> change in that anyone using those extension methods will now need to add
> the groovy-jaxb
> dependency into their build if they were previously relying on getting it
> from the groovy-all
> "fat" pom. Given that it was only introduced in 2.5.0, the number of
> affected users should
> be small. But the upside is that most users won't need to worry about using
> '--add-modules javax.xml.bind' or similar dependency tweaks when running
> on JDK9+
> to fix up the planned breakage introduced by those JDK versions.
>
> Feedback welcome.
>
> [1] https://issues.apache.org/jira/browse/GROOVY-8666
> [2] https://issues.apache.org/jira/browse/GROOVY-8671
>
> cheers, Paul.
>
>

Re: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

[Cédric Champeau]

I vote for option 3

Le jeu. 14 juin 2018 à 18:46, Russel Winder  a écrit :

> On Wed, 2018-06-13 at 14:53 -0400, Keith Suderman wrote:
> > >
> […]
> > How about an option #4.  If you are planning to do one more release of
> 2.6.0
> > anyway just drop the 'alpha' from the name and announce that it is the
> first
> > and last 2.6.x release expected.
> >
>
> I think this would be a bad idea. We haven't had any beta releases, nor RC
> releases. To jump to a final release strikes me as failure of proper
> process.
>
> Also leaving 2.6.0-alpha-3 as the last 2.6 release clearly indicates it is
> a
> retired version series. It also leaves it open much better for someone to
> pick
> it up should they so wish.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

[Cédric Champeau]

2018-04-10 11:52 GMT+02:00 Marcin Erdmann :

> Yeah, I've noticed the zip packaging in pom but wasn't sure if that's the
> reason why Gradle tries to resolve the jar for that artifact. Should I
> create an issue for it?
>

Yes, please :) Note that Maven behaves the same and tries to download the
jar too.

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

[Cédric Champeau]

There's a bug in the published pom: it says zip
instead of pom. We should fix this, thanks for the
report!



2018-04-09 23:15 GMT+02:00 Marcin Erdmann :

> Paul,
>
> I'm having a go at giving this release a spin by updating Geb's build to
> use it but unfortunately I'm not having any luck with trying to use the
> groovy-all artifact. I understand from the earlier thread about updates to
> the build on the dev list that the jar for that artifact is not published
> and it's supposed to just be a dependency only aritfact which will be
> useful for resolving all of Groovy's modules.
>
> To quote you:
>
> > The idea (once finished) is that you can still depend on a groovy-all 
> > dependency
> via Maven or Gradle and you'll automatically get the multiple required
> equivalent jars of the current single groovy-all jar.
>
> Unfortunately this is not the case. Given a simple build like:
>
>
> plugins {
> id 'groovy'
> }
>
> repositories {
> mavenCentral()
> }
>
> dependencies {
> compile 'org.codehaus.groovy:groovy-all:2.5.0-rc-1'
> }
>
>
> and an empty Groovy class in the main source set when running `gradle
> build` I'm getting:
>
>
> Could not resolve all dependencies for configuration ':compileClasspath'.
> > Could not find groovy-all.jar (org.codehaus.groovy:groovy-
> all:2.5.0-rc-1).
>   Searched in the following locations:
>   https://repo1.maven.org/maven2/org/codehaus/groovy/
> groovy-all/2.5.0-rc-1/groovy-all-2.5.0-rc-1.jar
>
>
> I tried changing the dependency to 'org.codehaus.groovy:groovy-
> all:2.5.0-rc-1@pom' but while in that case dependency resolution phase 
> succeeds
> the build itself then fails with:
>
>
> Cannot infer Groovy class path because no Groovy Jar was found on class
> path: configuration ':compileClasspath'
>
>
> I do not see any of the modules apart from groovy-all itself being added
> to the configuration when running `gradle dependencies --configuration
> compile`:
>
>
> compile - Dependencies for source set 'main'.
> \--- org.codehaus.groovy:groovy-all:2.5.0-rc-1
>
>
> Am I doing something wrong or is the way forward not using groovy-all
> anymore and explicitly depending on only the used modules?
>
> Cheers,
> Marcin
>
> On Mon, Apr 9, 2018 at 7:07 AM, Paul King  wrote:
>
>> Dear community,
>>
>> The Apache Groovy team is pleased to announce version 2.5.0-rc-1 of
>> Apache Groovy.
>> Apache Groovy is a multi-faceted programming language for the JVM.
>> Further details can be found at the http://groovy.apache.org website.
>>
>> This is a pre-release of a new version of Groovy.
>> We greatly appreciate any feedback you can give us when using this
>> version.
>>
>> This release includes 18 bug fixes/improvements as outlined in the
>> changelog:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12318123=12342817
>>
>> Sources, convenience binaries, downloadable documentation and an SDK
>> bundle can be found at: http://www.groovy-lang.org/download.html
>> We recommend you verify your installation using the information on that
>> page.
>>
>> Jars are also available within the major binary repositories.
>>
>> We welcome your help and feedback and in particular want
>> to thank everyone who contributed to this release.
>>
>> For more information on how to report problems, and to get involved,
>> visit the project website at https://groovy.apache.org/
>>
>> Best regards,
>>
>> The Apache Groovy team.
>>
>
>

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

[Cédric Champeau]

Thanks, I indeed missed this page.

2018-04-09 11:50 GMT+02:00 Paul King <pa...@asert.com.au>:

> We have the "by hand" release note summary (though I observe that it needs
> further updates):
>
> http://groovy-lang.org/releasenotes/groovy-2.5.html
>
> We can certainly also list the aggregate Jira issues (but with over 250
> issues it is a little hard to understand at a glance):
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20GROOVY%20AND%
> 20fixVersion%20in%20%282.5.0-alpha-1%2C%202.5.0-beta-1%2C%
> 202.5.0-beta-2%2C%202.5.0-beta-3%2C%202.5.0-rc-1%29
>
> I couldn't see an easy way to produce the "release note" format using
> multiple versions but if someone can let me know if that can be done, we
> can add that instead.
>
> Cheers, Paul.
>
> On Mon, Apr 9, 2018 at 5:20 PM, Cédric Champeau <cedric.champ...@gmail.com
> > wrote:
>
>> Hi Paul,
>>
>> Thanks for making this release. It would be nice to have _cummulative_
>> change log/release notes since 2.4. As they are now, the notes are pretty
>> useless as it doesn't indicate what changes from the last major release.
>>
>> WDYT?
>>
>> 2018-04-09 8:07 GMT+02:00 Paul King <pa...@apache.org>:
>>
>>> Dear community,
>>>
>>> The Apache Groovy team is pleased to announce version 2.5.0-rc-1 of
>>> Apache Groovy.
>>> Apache Groovy is a multi-faceted programming language for the JVM.
>>> Further details can be found at the http://groovy.apache.org website.
>>>
>>> This is a pre-release of a new version of Groovy.
>>> We greatly appreciate any feedback you can give us when using this
>>> version.
>>>
>>> This release includes 18 bug fixes/improvements as outlined in the
>>> changelog:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>> ctId=12318123=12342817
>>>
>>> Sources, convenience binaries, downloadable documentation and an SDK
>>> bundle can be found at: http://www.groovy-lang.org/download.html
>>> We recommend you verify your installation using the information on that
>>> page.
>>>
>>> Jars are also available within the major binary repositories.
>>>
>>> We welcome your help and feedback and in particular want
>>> to thank everyone who contributed to this release.
>>>
>>> For more information on how to report problems, and to get involved,
>>> visit the project website at https://groovy.apache.org/
>>>
>>> Best regards,
>>>
>>> The Apache Groovy team.
>>>
>>
>>
>

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

[Cédric Champeau]

Hi Paul,

Thanks for making this release. It would be nice to have _cummulative_
change log/release notes since 2.4. As they are now, the notes are pretty
useless as it doesn't indicate what changes from the last major release.

WDYT?

2018-04-09 8:07 GMT+02:00 Paul King :

> Dear community,
>
> The Apache Groovy team is pleased to announce version 2.5.0-rc-1 of
> Apache Groovy.
> Apache Groovy is a multi-faceted programming language for the JVM.
> Further details can be found at the http://groovy.apache.org website.
>
> This is a pre-release of a new version of Groovy.
> We greatly appreciate any feedback you can give us when using this version.
>
> This release includes 18 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318123=12342817
>
> Sources, convenience binaries, downloadable documentation and an SDK
> bundle can be found at: http://www.groovy-lang.org/download.html
> We recommend you verify your installation using the information on that
> page.
>
> Jars are also available within the major binary repositories.
>
> We welcome your help and feedback and in particular want
> to thank everyone who contributed to this release.
>
> For more information on how to report problems, and to get involved,
> visit the project website at https://groovy.apache.org/
>
> Best regards,
>
> The Apache Groovy team.
>

Re: Upgrade Groovy jar - can't start tomcat

[Cédric Champeau]

Thanks for the explanation, Paul, it makes sense. Long story short: do not
upgrade major libraries in bugfix releases ;)

2018-03-21 14:38 GMT+01:00 Paul King <pa...@asert.com.au>:

> The ASM 6 jar has a module-info.class file that gets incorporated into our
> jar via jarjar. We obviously should exclude that in our build and we do. We
> originally only had that build fix for 2_5_X and above builds because we
> didn't want to bump ASM version in a point release - but that change was
> later made without the accompanying build fix and that caused the
> module-info.class problem to resurface in 2.4.14 as well as cause several
> other bugs. The ASM change has been reverted for now, until we see whether
> the other issues can also be fixed. I'll do a 2.4.15 release after
> 2.5.0-rc1 so we have a more JDK9 friendly 2_4_X release.
>
> Cheers, Paul.
>
> On Wed, Mar 21, 2018 at 10:48 PM, Cédric Champeau <
> cedric.champ...@gmail.com> wrote:
>
>> The question is why do we have a `module-info.class` file in groovy.jar.
>> I thought we had fixed that. Or maybe in 2.4.15?
>>
>> 2018-03-21 13:46 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>:
>>
>>>
>>>
>>> Am 21.03.2018 um 12:34 schrieb Blake McBride:
>>>
>>>> Thanks!  Turns out, this is a known problem with older versions of
>>>> tomcat.  I don't think any changes in groovy are necessary.
>>>>
>>>
>>> just in case you are somebody else wants to know more
>>>
>>> Unable to process Jar entry [module-info.class] from Jar
>>> [jar:file:/.../build/web/WEB-INF/lib/groovy-2.4.14.jar!/] for
>>> annotations
>>> org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid
>>> byte tag in constant pool: 19
>>>
>>>
>>> module-info.class is for Java9 and requires a special flag available
>>> only in Java9 and later (constant pool entry with id 19). Thus for Tomcat
>>> under Java 8 the only solution is to ignore that or use a newer version of
>>> bcel that supports java9 and then ignore it. Because you cannot load it.
>>>
>>> bye Jochen
>>>
>>
>>
>

Re: Upgrade Groovy jar - can't start tomcat

[Cédric Champeau]

The question is why do we have a `module-info.class` file in groovy.jar. I
thought we had fixed that. Or maybe in 2.4.15?

2018-03-21 13:46 GMT+01:00 Jochen Theodorou :

>
>
> Am 21.03.2018 um 12:34 schrieb Blake McBride:
>
>> Thanks!  Turns out, this is a known problem with older versions of
>> tomcat.  I don't think any changes in groovy are necessary.
>>
>
> just in case you are somebody else wants to know more
>
> Unable to process Jar entry [module-info.class] from Jar
> [jar:file:/.../build/web/WEB-INF/lib/groovy-2.4.14.jar!/] for annotations
> org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte
> tag in constant pool: 19
>
>
> module-info.class is for Java9 and requires a special flag available only
> in Java9 and later (constant pool entry with id 19). Thus for Tomcat under
> Java 8 the only solution is to ignore that or use a newer version of bcel
> that supports java9 and then ignore it. Because you cannot load it.
>
> bye Jochen
>

Re: Groovy Champions proposal feedback

[Cédric Champeau]

I think it would be valuable to add a few examples of profiles who might be
entitled Groovy champion. Let me start:

- a speaker, teacher who by their public talks contributed to the awareness
of the language
- the author of a successful framework who, by leveraging Groovy,
introduced innovative features

2018-02-26 9:17 GMT+01:00 Paul King :

>
>
> On Mon, Feb 26, 2018 at 5:55 PM, Søren Berg Glasius 
> wrote:
>
>> @Mario
>>
>> Very good thoughts, I really like the idea that an award is permanent, I
>> believe that goes for Java Champs as well.
>>
>> Naming wise, Groovyssimo is fun, but not naming material for an award :-)
>> But we need to narrow down the name-space to something realistic that can
>> be voted on.
>>
>
> Agreed on the good thoughts comment. Well, I guess you are going to rule
> out my spin on Nobel with the No-semis award idea too! :-)
>
> No-semis jokes aside, we have been given feedback from within Apache that
> we have to make sure that we cover off whatever we do in terms of Apache
> branding, making sure that the trademark Apache Groovy is honored and that
> such a scheme could never head down a path that would be in conflict with
> the ASF directions. Also, as Cédric mentions we need to make a case why
> existing schemes like "committer status" or "PMC status" might not apply. I
> agree with Guillaume that the idea of the award has always been for the
> entire ecosystem and the existing mechanisms for recognizing contributions
> to the Apacge Groovy project don't really apply well in the broader
> community context. Much like the ASF itself has different kinds of awards,
> e.g. member of the ASF vs committer/PMC for a particular project, I think a
> different award is needed here.
>
> Cheers, Paul.
>
> On Mon, 26 Feb 2018 at 08:50 Mario Garcia  wrote:
>>
>>> +1 to what Guillaume said :) Common guys! Lets focus on what we think is
>>> a great language and let others think what they want!
>>>
>>> Regarding the duration of the award. I've though about it, trying not to
>>> think in terms of annually or permanent, but trying to see what's out there
>>> outside the CS world, and I ended up thinking on the Nobel prize. I'd like
>>> some ideas of Nobel prize:
>>>
>>>- Takes place every year
>>>- A given prize could be vacant a given year.
>>>- It's so important that it's really noticeable to be awarded
>>>- Makes people very proud of some achievement they did a given year
>>>- Once you're a Nobel you will always be a Nobel.
>>>- Of  course there's been awarded people that even rejected the
>>>prize but that never really underrated the prize overtime
>>>- New members are chosen by previous members and some other relevant
>>>people (members of the parliament among others). Here I'd add the
>>>idea of letting anybody to propose a nominee, but leaving the final
>>>decision to the prize committee (whatever we decide who is in)
>>>
>>> Despite the difference of content between the Nobel prize and the Groovy
>>> awards, after reviewing these points I think they seem to fit better in the
>>> Groovy Champions/Stars idea. There is also something I haven't heard yet. I
>>> guess this will require a kind of permanent organization, e.g. to contact
>>> members, nominees, organize the awards, a web to show the winners...etc
>>>
>>> BTW: Here you have another naming for the awards: Groovisimo Awards. Can
>>> you imaging a "Groovisimo" statue like the Oscars ? It would be a blast
>>> X
>>>
>>> My two cents
>>> Mario
>>>
>>> 2018-02-25 10:53 GMT+01:00 Guillaume Laforge :
>>>
 James Stachan's quote has really been taken out of context, and
 over-exagerated bu the Scala-fanboys.
 If Scala had been what it is now, James would probably not have
 initiated Groovy *then*. But Scala was nascent just like Groovy *then*.
 It's like if Gavin King had said that he wouldn't have invented
 Hibernate if JPA had existed... but JPA came ten years later.

 This quote was really harmful, but as the saying goes, lots of water's
 gone through the bridges since then.

 There's still the myth of slowliness, which we all know is not true
 anymore, even in pure dynamic mode (without even mentioning static
 compilation)
 Usually, you spend way more time in network latency (access to remote
 resources, access to database, etc) than waiting for the CPU spent by just
 the pure language execution time.

 Also back on James Strachan: he went to play with Scala, then with
 Kotlin, and has come back to using Groovy.
 He's using Groovy on a regular basis through his work with Jenkins, its
 pipelines, etc.
 So he's back at his old love!

 So let's turn the page on those stories, please.

 Guillaume


 On Sun, Feb 25, 2018 at 10:26 AM, Daniel Sun 
 wrote:

> The 

Re: Groovy Champions proposal feedback

[Cédric Champeau]

It feels like everybody agrees this is a good idea, but somethings hasn't
been discussed so far: the Foundation already has 2 ways of recognizing
members of the community:

1. by making them "committers"
2. by making them members of the PMC

If Groovy Champions is going to be different, we need a good explanation
why it doesn't fit in those 2 categories. Especially to give to the Board.
I have my ideas why, but I'd like to hear what others say.

2018-02-26 8:55 GMT+01:00 Søren Berg Glasius :

> @Mario
>
> Very good thoughts, I really like the idea that an award is permanent, I
> believe that goes for Java Champs as well.
>
> Naming wise, Groovyssimo is fun, but not naming material for an award :-)
> But we need to narrow down the name-space to something realistic that can
> be voted on.
>
>
>
> On Mon, 26 Feb 2018 at 08:50 Mario Garcia  wrote:
>
>> +1 to what Guillaume said :) Common guys! Lets focus on what we think is
>> a great language and let others think what they want!
>>
>> Regarding the duration of the award. I've though about it, trying not to
>> think in terms of annually or permanent, but trying to see what's out there
>> outside the CS world, and I ended up thinking on the Nobel prize. I'd like
>> some ideas of Nobel prize:
>>
>>- Takes place every year
>>- A given prize could be vacant a given year.
>>- It's so important that it's really noticeable to be awarded
>>- Makes people very proud of some achievement they did a given year
>>- Once you're a Nobel you will always be a Nobel.
>>- Of  course there's been awarded people that even rejected the prize
>>but that never really underrated the prize overtime
>>- New members are chosen by previous members and some other relevant
>>people (members of the parliament among others). Here I'd add the
>>idea of letting anybody to propose a nominee, but leaving the final
>>decision to the prize committee (whatever we decide who is in)
>>
>> Despite the difference of content between the Nobel prize and the Groovy
>> awards, after reviewing these points I think they seem to fit better in the
>> Groovy Champions/Stars idea. There is also something I haven't heard yet. I
>> guess this will require a kind of permanent organization, e.g. to contact
>> members, nominees, organize the awards, a web to show the winners...etc
>>
>> BTW: Here you have another naming for the awards: Groovisimo Awards. Can
>> you imaging a "Groovisimo" statue like the Oscars ? It would be a blast
>> X
>>
>> My two cents
>> Mario
>>
>> 2018-02-25 10:53 GMT+01:00 Guillaume Laforge :
>>
>>> James Stachan's quote has really been taken out of context, and
>>> over-exagerated bu the Scala-fanboys.
>>> If Scala had been what it is now, James would probably not have
>>> initiated Groovy *then*. But Scala was nascent just like Groovy *then*.
>>> It's like if Gavin King had said that he wouldn't have invented
>>> Hibernate if JPA had existed... but JPA came ten years later.
>>>
>>> This quote was really harmful, but as the saying goes, lots of water's
>>> gone through the bridges since then.
>>>
>>> There's still the myth of slowliness, which we all know is not true
>>> anymore, even in pure dynamic mode (without even mentioning static
>>> compilation)
>>> Usually, you spend way more time in network latency (access to remote
>>> resources, access to database, etc) than waiting for the CPU spent by just
>>> the pure language execution time.
>>>
>>> Also back on James Strachan: he went to play with Scala, then with
>>> Kotlin, and has come back to using Groovy.
>>> He's using Groovy on a regular basis through his work with Jenkins, its
>>> pipelines, etc.
>>> So he's back at his old love!
>>>
>>> So let's turn the page on those stories, please.
>>>
>>> Guillaume
>>>
>>>
>>> On Sun, Feb 25, 2018 at 10:26 AM, Daniel Sun 
>>> wrote:
>>>
 The creator of Groovy said "I can honestly say if someone had shown me
 the
 Programming in Scala book...". I think he compared Scala with the old
 version of Groovy he created in about 2003. As we all know, Groovy has
 evolved a lot, so I never care about others' out-dated opinions on
 Groovy :)

 Cheers,
 Daniel.Sun



 --
 Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

>>>
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer & PMC Vice-President
>>> Developer Advocate @ Google Cloud Platform
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge  / Google+
>>> 
>>>
>>
>> --
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>

Re: Groovy Champions proposal feedback - Groovy MVPs ?

[Cédric Champeau]

I agree with Guillaume: MVP sounds "Minimal Viable Product" in my head :)
Anoter option: VIP ;)

2018-02-20 8:32 GMT+01:00 Jennifer Strater :

> Although there seems to be a lot of disagreement about the name, everyone
> seems to be in favor of the idea. What is the next step, Paul?
>
>
> On 20. Feb 2018, at 07:56, Peter McNeil  wrote:
>
> You're all missing the obvious "Groovy GR8" :-)
>
> On 20/02/18 11:35, Paul King wrote:
>
> Supreme Thanks Award Recognising contributions? :-)
>
> On Tue, Feb 20, 2018 at 7:08 AM, Kostas Saidis  wrote:
>
>> My own few cents, too:
>>
>> Groovy Star, Groovy Champion, Groovy MVP all have their pros and cons. I
>> would suggest something along the lines of Groovy Exceptional Community
>> Member (Groovy ECM) or Groovy Distinguished Community Member (Groovy DCM).
>> New acronym, professional enough, focusing on the overall community and not
>> only the language per se.
>>
>> Kostas
>>
>>
>> On 19/2/2018 10:26 μμ, MG wrote:
>>
>> I have never heard "MVP" =  "Minimum Viable Product", so I doubt this
>> would pose a problem. Also do you suggest that people would actually read
>> "Groovy has announced its Minimum Viable Products of 2018" ?
>> STAR has 129 meanings as an acronym, btw, according to
>> https://acronyms.thefreedictionary.com/STAR
>>
>> On 19.02.2018 20:39, Guillaume Laforge wrote:
>>
>> For me, MVP sounds too much like Minimum Viable Product :
>> https://en.wikipedia.org/wiki/Minimum_viable_product
>>
>> On Mon, Feb 19, 2018 at 8:32 PM, MG  wrote:
>>
>>> Following the sports analogy, what about
>>>
>>> "Groovy MVPs"
>>>
>>> ?
>>>
>>> Any game can have Most Valuable Players (even if only one is typically
>>> crowned in the US), and I think "Groovy announced its 2018 MVPs" has a nice
>>> ring to it.
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>
>>> On 19.02.2018 12:03, Søren Berg Glasius wrote:
>>>
>>> I disagree with MG.
>>>
>>> A star is an object that shines, and in this case shines light on the
>>> Groovy language and ecosystem. Hence I think the name is both professional,
>>> and since it can be directly linked to the star in the Groovy logo I think
>>> it makes perfect sense. In sports you also have star players and in music
>>> (and Java) you have rock stars. That you can find examples that relates to
>>> games on Nintendo does not make a valid point IMO. The "All Stars" just
>>> makes it so much better - as that's what Paul, Jochen and others are .
>>>
>>> My few cents worth.
>>>
>>> /Søren
>>>
>>> On Sun, 18 Feb 2018 at 17:02 MG  wrote:
>>>


 On 18.02.2018 13:38, Eric Kinsella wrote:

 +1up on Groovy Stars.


 "Get a life" ;-)

 But seriously, all the people one-upping "Groovy Stars" - consider
 whether that name really sends the right professional message with regards
 to Groovy ? I am convinced it does not.
 Managers who might decide whether Groovy can be used in a project are
 typically conservative and sensitive to those things, and they do not
 normally follow nerd humor... (next suggestion I see coming along the
 Stars-crossed-line, is to call Paul and Jochen "Groovy All Stars")

 As another example, it looks like "Pokemon Stars" on the Nintendo
 Switch might become a reality:
 http://www.techradar.com/news/pokemon-stars-all-the-latest-l
 eaks-from-the-rumored-nintendo-switch-game




 On Sun, Feb 18, 2018 at 6:13 AM, Daniel Sun 
 wrote:

> Hi Paul,
>
>  “Groovy Champions” make people associate it with "Java Champions"
> easily. As for "Groovy Stars", it is interesting but let me associate
> "Song
> Stars" and "Kungfu Stars" easily... I wish other people would not
> associate
> as I do...
>
>   Similarly, many years ago some one suggested to name current
> "Grape"
> as "Groovy Baby", the latter is interesting but not formal...
>
>   To sum up, +1 to “Groovy Champions”.
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble
> .com/Groovy-Users-f329450.html
>


 --
>>> Best regards / Med venlig hilsen,
>>> Søren Berg Glasius
>>>
>>> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
>>> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
>>> --- Press ESC once to quit - twice to save the changes.
>>>
>>>
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge  / Google+
>> 
>>
>>
>>
>>
>
> --
> web: http://nerderg.com
> Twitter: http://twitter.com/pmcneil
> Google+: https://plus.google.com/u/0/communities/110661434396927001866
>
>

Re: Groovy Champions proposal feedback

[Cédric Champeau]

> Or for something with a bit more pep "Groovy Vanguard Developer /
> Contributor 2018" or "Groovy Crack 2018".
>
> Contrary to Java Champions, I would suggest tying it to a specific year:
>

I like the idea of having it associated with a year, but it doesn't have
to. Explanation below.


> That way people who no longer are Groovy contributors do not carry the
> title forever (the Russian guy who is now working on Kotlin comes to mind)
>

His name is Alex Tkachman, and while he's not involved in the language
anymore, he's still one of the biggest contributors to Groovy. Most of the
performance improvements in the "legacy" (non indy) dynamic runtime of
Groovy were from him and still active. He was also source of inspiration
for the static compiler (Groovy++). I think he deserves the title more than
lots of us. And I think we shouldn't go into the "he's gone to competition"
route. Languages evolve, Kotlin is a very nice language, that took
inspiration from us as well as others, and we have lots of things to learn
from it too.


> , and on the other hand some people could get the title several years in a
> row, as a sign of continued gratitude.
>
>
If they do, they would be good candidates for the PMC.


> Cheers,
> mg
>
>
>
> On 13.02.2018 14:13, Søren Berg Glasius wrote:
>
> +1 on the name!
>
> I think it's cool to differentiate the Groovy award from other awards like
> Java Rock-stars and Java Champions, Grails Rock-stars, and more!
>
>
> On Tue, 13 Feb 2018 at 14:09 Guillaume Laforge  wrote:
>
>> It's funny, I think we didn't think about "stars" in our previous
>> conversations, and I must say I quite like it, and it makes sense
>> considering our logo :-D
>>
>> On Tue, Feb 13, 2018 at 1:58 PM, Jennifer Strater > > wrote:
>>
>>> +1 for the proposal and +1 for "Groovy Stars"
>>>
>>> On Tue, Feb 13, 2018 at 1:54 PM, Paul King  wrote:
>>>
 I don't mind "Groovy Stars" as a name!

 Of course it begs the question "Star trek" or "Star Wars" - the long
 journey
 of programming language design vs the language wars! :-)


 On Tue, Feb 13, 2018 at 9:46 PM, Dierk König 
 wrote:

> I’m all for honoring contributions to the
> language/ecosystem/community.
> Given our logo, „Groovy Star“ comes to mind :-)
>
> Cheers
> Dierk
>
> sent from:mobile
>
> Am 13.02.2018 um 12:29 schrieb Paolo Di Tommaso <
> paolo.ditomm...@gmail.com>:
>
> It sound a nice idea also to promote the visibility of the groovy
> community.
>
>
> p
>
> On Tue, Feb 13, 2018 at 12:18 PM, Søren Berg Glasius <
> soe...@glasius.dk> wrote:
>
>> I'm definitely +1
>>
>> It is always important to recognize and encourage the ones making a
>> difference to the community.
>>
>> On Tue, 13 Feb 2018 at 11:32 Schalk Cronjé  wrote:
>>
>>>
>>> That's a +1 from me for the concep.
>>>
>>>
>>> On 13/02/2018 10:58, Paul King wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > A few of us have had various discussions (in fact over many years)
>>> > about having a recognition scheme similar to Java Champions,
>>> > perhaps called "Groovy Champions" or "Apache Groovy Champions"
>>> > or something else entirely if we think of a better name.
>>> >
>>> > I think the idea has always been to recognize contribution within
>>> the
>>> > whole Groovy ecosystem not just the Apache Groovy project. The many
>>> > tens of projects within the ecosystem are often where many ideas
>>> come
>>> > from for the project's future evolution and also where future
>>> contributors
>>> > may arise. And in any case, Groovy has always been about making
>>> > coding productive and fun and we should celebrate that widely!
>>> >
>>> > There are various questions to ask like should such a scheme
>>> > be formally coordinated by the project/by Apache or should it be
>>> run as a
>>> > community-driven unsanctioned activity and if so what guidelines
>>> should
>>> > be in place. Also, there are many details like how will the scheme
>>> > operate?
>>> > How are new members elected? Is it a lifetime recognition or is
>>> there
>>> > an "emeritus" status? And so forth. Java Champions vote themselves
>>> > on new champions and the recognition has a lifetime status for
>>> instance.
>>> > if we progress this idea, we'd need to make that all clear but
>>> that isn't
>>> > the purpose of this email - we need to first decide if we like the
>>> idea.
>>> >
>>> > Even if we like the idea, there are still some hurdles to step
>>> through.
>>> > We've already sought some informal feedback from other parts of
>>> > Apache and other projects within the Groovy Ecosystem and we'll
>>> > likely need 

Re: AST nodeMetaData

[Cédric Champeau]

Unless you have an AST xform that takes that node metadata and injects it
into bytecode in a way that it's available at runtime (say, within an
annotation), no, it's not possible.

2018-02-08 14:30 GMT+01:00 Paolo Di Tommaso :

> Dear all,
>
> Is it possible to inject some values in a nodeMetaData during AST
> transformation and access such values at runtime  ?
>
>
> p
>

Re: Need to get help: Building Groovy 1.7.5 from source gives encoding error for ReadLineTest.groovy

[Cédric Champeau]

Hi Ken,

I don't mean to scare you, but you're running on a very old version of
Groovy (1.7.5 is from 2010 !), which has several vulnerabilities. Anyway,
if you still want to do this, there are things you need to know:

1. the build was using Ant at this time, and not especially known to be
reproducible.
2. as you saw, the build missed some critical configuration like file
encoding, but by then some files were also encoded using different
encodings if I remember well
3. the compiler, especially by then, wasn't checked for reproducibility,
and for Groovy file at least, introduced some timestamps in binary class
files, making it by design not reproducible
4. even recent versions of the Groovy compiler had bugs that made outputs
non reproducible (runtime was, but the binary wasn't: this can happen if
you have to choose between 2 interfaces which provide the same method, and
you arbitrarily choose to call one over the other)
5. backporting a change like the GROOVY-5249, which was written for Groovy
2.3, looks very difficult at first glance: there were *many* changes in the
MOP in Groovy 2

So I don't want to kill your efforts, but I'm wondering if you really have
no other choice.

2018-02-08 12:33 GMT+01:00 Ken Lam :

> Dear Groovy developers,
>
> After experimenting with many JDK versions, I found that JDK 6 Update 13
> and 21 to be able to build the jar with the least difference from the
> official groovy-all-1.7.5.jar distributed in grails 1.3.5.
>
> But I still want to know whether the difference in the binary .class files
> will have impact to my system.
>
> Attached are the samples and summary of "how different" the jar built by
> me is from the official groovy-all-1.7.5.jar
>
> JDK 6 Update 13: 190 binary files different from official version
>
> JDK 6 Update 21: 198 binary files different from official version
>
>
> Apart from the "__timeStamp__239_neverHappen" timestamp in the .class
> files, there are still some other differences, and I want to know why they
> are here.
>
> I understand this is a lot to ask, but I have no choice because I don't
> know how to analyze the bytecode differences and their meanings. So I have
> attached some samples and I hope if you can teach me some basic knowledge
> and some references to look at, I will be able to handle it myself in the
> future.
>
> Regards,
>
> Ken Lam
> System Analyst
> Mobigator Technology Group
> http://www.mobigator.com
> T: +852.2524.9000, ext 114
> F: +852.2524.9050
>
>  Original Message 
> Subject: Re: Need to get help: Building Groovy 1.7.5 from source gives
> encoding error for ReadLineTest.groovy
> From: Ken Lam 
> To: users@groovy.apache.org, Jochen Theodorou 
> Date: 8/2/2018 11:18
>
>> Dear Jochen,
>>
>> More info I found from MANIFEST.MF:
>>
>> I found that the official groovy-all-1.7.5.jar distributed in grails
>> 1.3.5 was built with JDK 1.7.0-ea (Sun Microsystems Inc.). I guess the "ea"
>> means early access version. So I don't believe I could ever use the exactly
>> same JDK to compile the groovy source. How am I supposed to find an early
>> access version?
>>
>> Anyway, this is a less important question. As mentioned in previous
>> email, I mainly want to know whether it's expected or required, to compile
>> binary .class files which are identical to the officially distributed ones,
>> when we try to rebuild groovy on our own.
>>
>> Regards,
>>
>> Ken Lam
>> System Analyst
>> Mobigator Technology Group
>> http://www.mobigator.com
>> T: +852.2524.9000, ext 114
>> F: +852.2524.9050
>>
>>  Original Message 
>> Subject: Re: Need to get help: Building Groovy 1.7.5 from source gives
>> encoding error for ReadLineTest.groovy
>> From: Ken Lam 
>> To: users@groovy.apache.org, Jochen Theodorou 
>> Date: 8/2/2018 11:12
>>
>>> Dear Jochen,
>>>
>>> Also, after compiling the groovy-all-1.7.5.jar, I extracted the jar, and
>>> extracted the official jar distributed in grails 1.3.5, and compare between
>>> the two extracted folders.
>>>
>>> Out of 3371 files, 256 files (254 binary files + 2 text files) are
>>> different, and the rest are identical.
>>>
>>> For the 2 different text files, I have checked and they should be ok.
>>>
>>> For the 254 binary files, however, I am not sure whether this is normal.
>>>
>>> Of course, I haven't modified any source codes at all. At least not yet.
>>>
>>>
>>> My question is:
>>>
>>> Is it expected or required, to have exact binary .class files compiled
>>> when we try to rebuild groovy? My compiled jar does have nearly 3000 binary
>>> class files being identical to the those in the official jar, only 254
>>> binary files are different.
>>>
>>> Regards,
>>>
>>> Ken Lam
>>> System Analyst
>>> Mobigator Technology Group
>>> http://www.mobigator.com
>>> T: +852.2524.9000, ext 114
>>> F: +852.2524.9050
>>>
>>>  Original Message 
>>> Subject: Re: Need to get help: 

Re: Loading groovy as a Jigsaw auto-module

[Cédric Champeau]

Oh thanks for the clarification, Jochen, I didn't realize the problem was
with Maven itself. I think Maven over-interprets the spec. It's not because
you find a file in `META-INF/services` that it *must* be a service
descriptor.

Now for the extension mechanism, for sure we need to check what it means
for us.

2017-12-04 10:23 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>:

> Just to clarify things... This is a maven plugin complaining, not JDK9, as
> I see it. Afaik the plugin tries to create a module configuration for
> groovy and cannot interpret the services provided in those directories.
> JDK9 would not care, unless you say your module is providing a certain
> service.
>
> And I want to add two more points: The extension mechanism is unlikely to
> work as intended on JDK9. If you want to provide a service across modules
> you are now forced to use the very doubtful ServiceProvider infrastructure.
> And one module to read a file from another module was at least till late
> stages of JDK9 not possible. I am not sure what the latest state here was.
> Maybe I did interpret something wrong - writing a test for this would be
> easy.
>
> But if I am right, this would mean our extension mechanism must become a
> SPI structure to enable other modules to provide extension modules.
>
> Am 03.12.2017 um 19:01 schrieb Cédric Champeau:
>
>> This file is used by Groovy internally, there's no reason for the JDK to
>> interpret its contents since it has only a meaning for Groovy. In short, it
>> declares the list of extensions recognized by the Groovy compiler. That it
>> prevents loading as a module is rather strange.
>>
>> 2017-12-03 16:37 GMT+01:00 Ceki Gulcu <c...@qos.ch <mailto:c...@qos.ch>>:
>>
>> Hi all,
>>
>> Referring to a discussion on the maven users list [1], it appears that
>> removing the file
>> META-INF/services/org.codehaus.groovy.source.Extensions from
>> groovy-2.4.13.jar allows Java 9 to successfully load
>> groovy-2.4.13.jar as an auto-module.
>>
>> The org.codehaus.groovy.source.Extensions file contains the lone
>> word "groovy" instead of a fully qualified class name.
>>
>> Please advise.
>>
>> Best regards,
>>
>> --
>> Ceki Gülcü
>>
>> [1] http://markmail.org/message/obdyvuv24kqpxm6v
>> <http://markmail.org/message/obdyvuv24kqpxm6v>
>>
>>
>>

Re: Loading groovy as a Jigsaw auto-module

[Cédric Champeau]

So my understanding is that because this file is found in
META-INF/services, the JDK interprets its contents as being a service class
name provider, which is it not. We have quite a few files in there which
are "Groovy services" but nothing related to "Java services":

META-INF/services/javax.script.ScriptEngineFactory: references the JSR 223
class name. Service in the JDK semantics.
META-INF/services/org.apache.groovy.plugin.GroovyRunner : not quite sure
why it's there, seems rather new to me, and references a real class
(TestNgRunner)
META-INF/services/org.codehaus.groovy.runtime.ExtensionModule : Groovy's
extension module file. Doesn't reference services but it's more a
properties file referencing other class names
META-INF/services/org.codehaus.groovy.source.Extensions : possible Groovy
compiler extension file names listed here. Not a service.
META-INF/services/org.codehaus.groovy.transform.ASTTransformation : a list
of class names, which are not JDK services either.

So I have no clue why the JDK needs to read all those files and make sure
the service classes exist. But it would be a breaking change to move those
files somewhere else.


2017-12-03 19:01 GMT+01:00 Cédric Champeau <cedric.champ...@gmail.com>:

> This file is used by Groovy internally, there's no reason for the JDK to
> interpret its contents since it has only a meaning for Groovy. In short, it
> declares the list of extensions recognized by the Groovy compiler. That it
> prevents loading as a module is rather strange.
>
> 2017-12-03 16:37 GMT+01:00 Ceki Gulcu <c...@qos.ch>:
>
>> Hi all,
>>
>> Referring to a discussion on the maven users list [1], it appears that
>> removing the file META-INF/services/org.codehaus.groovy.source.Extensions
>> from groovy-2.4.13.jar allows Java 9 to successfully load groovy-2.4.13.jar
>> as an auto-module.
>>
>> The org.codehaus.groovy.source.Extensions file contains the lone word
>> "groovy" instead of a fully qualified class name.
>>
>> Please advise.
>>
>> Best regards,
>>
>> --
>> Ceki Gülcü
>>
>> [1] http://markmail.org/message/obdyvuv24kqpxm6v
>>
>
>

Re: Loading groovy as a Jigsaw auto-module

[Cédric Champeau]

This file is used by Groovy internally, there's no reason for the JDK to
interpret its contents since it has only a meaning for Groovy. In short, it
declares the list of extensions recognized by the Groovy compiler. That it
prevents loading as a module is rather strange.

2017-12-03 16:37 GMT+01:00 Ceki Gulcu :

> Hi all,
>
> Referring to a discussion on the maven users list [1], it appears that
> removing the file META-INF/services/org.codehaus.groovy.source.Extensions
> from groovy-2.4.13.jar allows Java 9 to successfully load groovy-2.4.13.jar
> as an auto-module.
>
> The org.codehaus.groovy.source.Extensions file contains the lone word
> "groovy" instead of a fully qualified class name.
>
> Please advise.
>
> Best regards,
>
> --
> Ceki Gülcü
>
> [1] http://markmail.org/message/obdyvuv24kqpxm6v
>

Re: Consider statically typed/compiled as default for Groovy 3.0

[Cédric Champeau]

Wise words, Paul. I would also very much prefer to see progress in the Java
9 area rather than this, or even the parser. It's much more relevant to the
future of Groovy IMHO. Because, as the ticket explains, there's already
ways to enable this feature (even if a bit cumbersome). It's really of that
importance, then a pull request, accepted through a VOTE, would certainly
be the fastest way to get this.

2017-10-13 15:11 GMT+02:00 Paul King :

> I think most committers are also keen on making progress in the directions
> you describe. Not along the lines of watering down Groovy's dynamic
> capabilities but certainly in terms of making Groovy's static nature as
> hassle free as possible to use. Having said that, we have limited
> resources, so we need to prioritise and do a limited numbers of things well
> rather than half do lots of things. Most of us have our own long list of
> technical issues that we think need working on (jdk9 support, new parser,
> bugs we know of in static type checking, many other features we'd like,
> etc.), so if you aren't seeing a lot of traction for this idea, it is
> possibly because we see a big list of things that would be needed to be
> sorted out to do this well and we are weighing up that list with our
> already long todo lists.
>
> Perhaps we wear our technical hats too much and should put on our
> marketing hats a bit more - who knows. All I can suggest to you is that
> Apache Groovy follows the Apache do-ocracy culture. If anyone picks off a
> small piece of the puzzle and advances it forward, it is likely to
> progress. But it's not guaranteed, so you are doing the right thing by
> discussing on the mailing lists. If you still don't get traction, start
> again with a smaller step.
>
> Cheers, Paul.
>
> On Fri, Oct 13, 2017 at 6:30 AM, MG  wrote:
>
>> blackdrag suggested to move this
>> https://issues.apache.org/jira/browse/GROOVY-8329
>> discussion from Jira to this list, so I am replying here:
>>
>> I agree with Endre Stølsvik: I think Groovy should strengthen its
>> language support for statically compiled use, and I agree it should move
>> towards making statically using it as hassle free as possible.
>>
>> I think Endre has already made some good points why this would be a good
>> idea, so I am just going to add that I am convinced that Groovy would not
>> be at 3% of the languages used after Java, but at > 30% (basically everyone
>> that could freely pick a language for commercial projects besides Java
>> would be using it) if it would fully be the Java++ it in fact is - in my
>> perception what kept it back was the fact that it "is slow" (true > 10
>> years back), that it is just "a script language" (never true afaik) - and
>> that it "is a dynamic language" (no longer true, but...). When I picked
>> Groovy for the project I work on, I did so despite it was dynamic, not
>> because of that (the static Groovy compiler that someone in Russia had
>> built at the time helped in the decision...).
>>
>> Being able to be dynamic in a language is a powerful feature, but one
>> that is needed only in special cases. Otherwise Groovy would already rule
>> the Java world ;-)
>>
>> Being able to have a very simple configscript that qualifies every class
>> with @CompileStatic is great (http://docs.groovy-lang.org/l
>> atest/html/documentation/#_static_compilation_by_default), but it is not
>> simple/easy enough: I agree there should be a "one click" option to turn
>> all of Groovy to using static compilation by default.
>>
>> Some ways to achieve this:
>> # Make a "static Groovy" download available (might just be based on
>> "including" the @CompileStatic configscript above)
>> # Compiler switch
>> # Choose during installation
>> # Express through the Groovy source file extension:
>> ## *.groovy ... use configured default
>> ## *.groovyd ... dynamic
>> ## *.groovys ... static
>> (alternatives: *.groovys, *.sgrv, *.grvs)
>>
>> The last option has the advantage, that everybody can use it easily
>> everwhere (Shell, IDE, ...), but the disadvantage that all the Groovy
>> examples out there use *.groovy, which would again might give the
>> impression to people that Groovy is "mostly a dynamic language". Maybe a
>> combination of people picking the default mode (dynamic/static) at
>> download/install time, with the extension approach would work best.
>> (That the Groovy compiler will try to compile any file with any extension
>> is OK. In that case I would suggest the fallback if the extension is not
>> known is dynamic compilation, for backward compatibility reasons.
>> Configuring extensions to mean dynamic or static compilation would of
>> course also be an option).
>> Or the Groovy compiler could throw if no --static or --dynamic compiler
>> switch was given ? That would force everyone to make a deliberate
>> decision... ;-)
>>
>> Just a quick brainstorming mail, to hopefully get the discussion going,
>> Markus
>>
>>
>>
>

Re: Maven coordinates going forward

[Cédric Champeau]

>
>
>
>
> Is this not the whole point of releasing versioned binaries?  It just
> means a couple of extra steps when I upgrade.  First, change the
> coordinates (group + version instead of just the version) and a quick
> refactor of my imports.  Every modern IDE makes this easy.
>
>
> This is not much about direct dependencies, but about transitive
dependencies. Exclusions in Maven are horrible. You never want to exclude a
dependency. What you really want is to substitute it, so that it can belong
to the dependency resolution process.

Re: Maven coordinates going forward

[Cédric Champeau]

And again, _we have no choice_. If we want Groovy to run as a module, we
HAVE to break binary compatibility. There's absolutely no other way around.
It's a thing. If we don't want to break it, Groovy will never run as a
module. And if JDK 9 modules become legion, then Groovy would die.

2017-03-30 15:16 GMT+02:00 Cédric Champeau <cedric.champ...@gmail.com>:

> To me the idea would be to be able to run Groovy 2 and Groovy NG
> concurrently.
>
> 2017-03-30 15:12 GMT+02:00 Winnebeck, Jason <Jason.Winnebeck@windstream.
> com>:
>
>> Can you explain the story around a library like
>> org.codehaus.groovy.modules.http-builder:http-builder, which is no
>> longer really maintained? What happens to such a library when Groovy 3
>> comes out and we are using that library? Let's say there is no maintainer
>> to update the sources to Groovy 3 and re-release.
>>
>> Jason
>>
>> -Original Message-
>> From: Russel Winder [mailto:rus...@winder.org.uk]
>> Sent: Thursday, March 30, 2017 3:54 AM
>> To: users@groovy.apache.org
>> Subject: Re: Maven coordinates going forward
>>
>> On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
>> > We have to keep in mind that there's a larger story here, which is
>> > supporting Groovy as a module. And this *will* require package changes
>> > and binary breaking changes. So I don't think the status quo is
>> > acceptable in the long run.
>>
>> So why not make Groovy 3 the place to do this?
>>
>> Whatever has been said about the Python situation, the core problem was
>> not the breaking change, the problem was the lack of active management of
>> the change.
>>
>> Python is a source deployment language where JRE-based langauges are not.
>> Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran
>> problem of "we've lost the source" (banks and governments are the usual
>> suspects for this). I would exclude this situation from our thinking.
>> Organisations in such a state (as some UK banks and the UK government is)
>> should take it as an opportunity to revolutionise (which the UK government
>> is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people
>> who also know Python, Java, etc.
>>
>> Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
>> 3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in
>> the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix
>> made for a much, much easier time. So initially moving from Python
>> 2 to Python 3 was a manual task (bad management by the Python 3 folk),
>> then came the six generation of upgrade tooling (a start). By dropping
>> 2.6 and 3.3, we get the far nicer future upgrade tooling (which works
>> nicely to create 2.7 and 3.4+ compatible code). The moral here is choose
>> the versions being upgraded from and to, and then make some nice automation.
>>
>> So if we assume a base of Groovy 2.4 and ignore all previous Groovys and
>> the breaking change of 3.0 can we write some Groovy (obviously :-) scripts
>> that automate source changes?
>>
>> If the Python 2 → Python 3 breaking change had been more actively managed
>> with earlier arrival of six and future, the problems would have been much
>> less. Most of the vocal Python 2 Remainers have now made their codes run on
>> both Python 2 and Python 3, and there are very few complaints about
>> providing Python 3 only. OK so there are still a few people who say "we
>> must support Python 2.5" but those people are few and far between and are,
>> in the main, totally ignored. Python 4 will undoubtedly have breaking
>> changes, but they will be better managed in terms of supporting
>> multi-version working and automated (well at least
>> semi-automated) upgrading and mixed-version working. The lessons of six
>> and future have been well learned.
>>
>> So Groovy will have breaking changes, this is right and proper. Put in
>> place tools for upgrading, and support multi-version working where possible
>> and practical. Do not be swayed by calls for "we must change nothing,
>> backward compatibility". They have a version of Groovy that works for them
>> so they should not upgrade – ever again. That must not stop the rest of us
>> from progressing.
>>
>> --
>> Russel.
>> 
>> =
>> Dr Russel Winder  t: +44 20 7585 2200 <+44%2020%207585%202200>
>>  voip: sip:russel.win...@ekiga.net
>> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
>> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>
>> This email message and any attachments are for the sole use of the
>> intended recipient(s). Any unauthorized review, use, disclosure or
>> distribution is prohibited. If you are not the intended recipient, please
>> contact the sender by reply email and destroy all copies of the original
>> message and any attachments.
>>
>
>

Re: Maven coordinates going forward

[Cédric Champeau]

To me the idea would be to be able to run Groovy 2 and Groovy NG
concurrently.

2017-03-30 15:12 GMT+02:00 Winnebeck, Jason <jason.winneb...@windstream.com>
:

> Can you explain the story around a library like
> org.codehaus.groovy.modules.http-builder:http-builder, which is no longer
> really maintained? What happens to such a library when Groovy 3 comes out
> and we are using that library? Let's say there is no maintainer to update
> the sources to Groovy 3 and re-release.
>
> Jason
>
> -Original Message-
> From: Russel Winder [mailto:rus...@winder.org.uk]
> Sent: Thursday, March 30, 2017 3:54 AM
> To: users@groovy.apache.org
> Subject: Re: Maven coordinates going forward
>
> On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> > We have to keep in mind that there's a larger story here, which is
> > supporting Groovy as a module. And this *will* require package changes
> > and binary breaking changes. So I don't think the status quo is
> > acceptable in the long run.
>
> So why not make Groovy 3 the place to do this?
>
> Whatever has been said about the Python situation, the core problem was
> not the breaking change, the problem was the lack of active management of
> the change.
>
> Python is a source deployment language where JRE-based langauges are not.
> Thus JRE-based application have the classic COBOL, FORTRAN, and Fortran
> problem of "we've lost the source" (banks and governments are the usual
> suspects for this). I would exclude this situation from our thinking.
> Organisations in such a state (as some UK banks and the UK government is)
> should take it as an opportunity to revolutionise (which the UK government
> is, cf. the job adverts for COBOL, FORTRAN and Fortran knowledgeable people
> who also know Python, Java, etc.
>
> Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
> 3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in
> the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the mix
> made for a much, much easier time. So initially moving from Python
> 2 to Python 3 was a manual task (bad management by the Python 3 folk),
> then came the six generation of upgrade tooling (a start). By dropping
> 2.6 and 3.3, we get the far nicer future upgrade tooling (which works
> nicely to create 2.7 and 3.4+ compatible code). The moral here is choose
> the versions being upgraded from and to, and then make some nice automation.
>
> So if we assume a base of Groovy 2.4 and ignore all previous Groovys and
> the breaking change of 3.0 can we write some Groovy (obviously :-) scripts
> that automate source changes?
>
> If the Python 2 → Python 3 breaking change had been more actively managed
> with earlier arrival of six and future, the problems would have been much
> less. Most of the vocal Python 2 Remainers have now made their codes run on
> both Python 2 and Python 3, and there are very few complaints about
> providing Python 3 only. OK so there are still a few people who say "we
> must support Python 2.5" but those people are few and far between and are,
> in the main, totally ignored. Python 4 will undoubtedly have breaking
> changes, but they will be better managed in terms of supporting
> multi-version working and automated (well at least
> semi-automated) upgrading and mixed-version working. The lessons of six
> and future have been well learned.
>
> So Groovy will have breaking changes, this is right and proper. Put in
> place tools for upgrading, and support multi-version working where possible
> and practical. Do not be swayed by calls for "we must change nothing,
> backward compatibility". They have a version of Groovy that works for them
> so they should not upgrade – ever again. That must not stop the rest of us
> from progressing.
>
> --
> Russel.
> 
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>

Re: Groovy compiler configuration BytecodeProcessor

[Cédric Champeau]

It can be used for various purposes: dumping the generated bytecode,
post-processing it (to avoid runtime instrumentation), storing generated
bytecode on disk, ... As for memory size a groovy script will allocate,
this statement is too blury: the only thing you can measure is the size of
the generated bytecode. It is impossible to know in advance how much a
script will "allocate" or use.

2017-03-30 14:14 GMT+02:00 Cherif Gouiaa :

> What is the exact role of a BytecodeProcessor when used in a
> org.codehaus.groovy.control.CompilerConfiguration.
>
> Can I rely on it to measure the memory size which a groovy script will
> allocate. (i.e. original.length) ?
>
> --
> *Cherif Gouiaa*
> Ingenieur de developpement
> [image: logo]
> --
> arismore - www.arismore.fr
> Siège : 137 Bureaux de la Colline - 92213 Saint-Cloud Cedex - France
> Agence Nord : 70 rue de l'Harmonie - Parc de la Haute Borne - 59650
> Villeneuve d'Ascq
> Agence Méditerranée : 375 avenue du mistral 13600 La Ciotat
> Standard : 01 55 57 21 60 - Fax : 01 55 57 04 45
>

Re: Official Docker Groovy images

[Cédric Champeau]

Good job Keegan!

Just nitpicking, but what does make those images official? Are they
endorsed by the ASF?

2017-03-02 1:37 GMT+01:00 Keegan Witt :

> I'm preparing to update for 2.4.9 and am considering two significant
> changes to the initial image.  First, to create a volume to prevent Grape
> caches from being put into downstream images (PR #6
> ), and using a user other
> than root for the container (PR #7
> ).  I'm pretty sure I'm
> going to do #6, should be pretty safe.  But I'm still weighing #7.  I wanna
> get that decided this week so that we pick something and stick with it, to
> avoid breaking anything later.  Please weigh in if you have any opinion.
>
> -Keegan
>
> On Wed, Mar 1, 2017 at 3:20 AM, Guillaume Laforge 
> wrote:
>
>> Well done, Keegan!
>>
>> On Wed, Mar 1, 2017 at 8:12 AM, Daniel Sun 
>> wrote:
>>
>>> Nice!
>>>
>>>
>>>
>>> --
>>> View this message in context: http://groovy.329449.n5.nabble
>>> .com/Official-Docker-Groovy-images-tp5738848p5738851.html
>>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge  / Google+
>> 
>>
>
>

Welcome to our new committer : Sergei Egorov

[Cédric Champeau]

Hi folks,

I'd like to introduce you to Sergei Egorov, our new Apache Groovy
committer! Some of you may already know Sergei for his work on macros,
which are going to make appearance in Apache Groovy 2.5. He is a very
talented developer with the skills we need to help Groovy move forward.

A warm welcome, and congratulations, to Sergei!

Sergei, would you mind telling a few words about you?

On behalf of the Apache Groovy team
Cédric

Re: .with() variant that returns the original object

[Cédric Champeau]

+1 to `tap`

2016-11-08 15:41 GMT+01:00 Guillaume Laforge :

> I quite like "tap" (like in wiretaping, you're looking through the pipe)
> We already have some rubyisms, so having one more is not a bad idea at all
> for consistency.
>
> "doto" doesn't really help me understand what the method is about.
>
> "apply" is too overloaded, for functional programming, etc, so I'd really
> avoid it.
>
> "tee" why not, but I didn't really knew what it was meanting.
>
> Not a big fan of auto, asThis, withThis or within.
>
> My preference clearly goes for tap!
>
> On Tue, Nov 8, 2016 at 3:34 PM, Paul King  wrote:
>
>> Hi everyone,
>>
>> We are hoping to release 2.5 not too far down the track. We are
>> working on a revamped release process that is going to dramatically
>> improve our ability to release early/release often but also comply
>> with some additional Apache requirements that we follow these days.
>> But more on that another time.
>>
>> One outstanding feature request targeted for potential inclusion in
>> 2.5 is an alternative to .with{} that automatically returns the
>> original object after executing the closure - recall that .with{}
>> returns the last evaluated expression. The proposal is here:
>>
>> https://github.com/apache/groovy/pull/174/files
>>
>> We can't use the old name since that would break backward
>> compatibility and is of utility in its current form in any case, so we
>> are looking for a new name for the proposed method. If you look at the
>> PR you will see it has been called 'tap' and 'doto' and numerous other
>> names have been suggested. We regard naming as very important and
>> normally we'd have very strong views about suitable names based on
>> functionality and similar method names within the Groovy codebase. But
>> in this instance, an obvious name hasn't popped out at us, so we are
>> requesting feedback from the community about what names make most
>> sense to you.
>>
>> Firstly, here is what the method does. I'll use 'tap' in these
>> examples since that is what the PR currently uses but we can easily
>> change that based on feedback.
>>
>> myObject.tap {
>> // some code
>> }
>>
>> is equivalent to:
>>
>> myObject.with {
>> // some code
>> return this
>> }
>>
>> Returning the 'self' object lends itself to various kinds of chaining,
>> e.g.
>>
>> assert [:].tap {
>> a = 1
>> }.tap {
>> b = 2
>> } == [a:1, b:2]
>>
>> Or this one (adapted from a blog post[1] - and assuming you have a
>> config.properties file containing answer=42 as one of the properties):
>>
>> assert new Properties().tap {
>> new FileInputStream('config.properties').withCloseable {
>> load(it)
>> }
>> }.answer == '42'
>>
>> Here are some of the names that have been suggested with some commentary:
>>
>> dotoUsed by Clojure. Not camel case as per normal convention
>> (though we have upto and downto which also break that convention) and
>> it isn't immediately obvious which is which between with and doto just
>> from the names
>>
>> tapComes from Ruby and a previous Groovy extension outside core
>> exists; meant to conjure up the idea of tapping into an object
>>
>> autoWithSame as with but automatically returns self
>>
>> doWith   Again, hard to distinguish between doWith and with from the
>> names themselves
>>
>> teeAn alternative name for tap
>>
>> autoA shortened version of 'autoWith'
>>
>> applysame as Kotlin which has copied Groovy's with but suffers
>> from the downside that apply is already heavily overleaded in other
>> contexts, e.g. functional programming
>>
>> withThisDistinction with normal with a bit subtle perhaps
>>
>> asThisDitto
>>
>> withinDitto
>>
>> I'll also point out the 'identity' is currently an alias for 'with',
>> in case that provides any additional inspiration.
>>
>> Perhaps you dis/like one of the above or have some other suggestions.
>> Let us know.
>>
>>
>> Cheers, Paul.
>>
>>
>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan
>> dard-library/
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: Congratulations to our newest committer Daniel Sun

[Cédric Champeau]

Congrats, Daniel!

2016-11-05 9:33 GMT+01:00 Daniel.Sun :

> Thanks :)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Congratulations-to-our-newest-committer-Daniel-
> Sun-tp5736468p5736502.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>

Re: Static type checking

[Cédric Champeau]

This is clearly a bug. Can you file a JIRA issue for this?

2016-09-02 15:05 GMT+02:00 cazacugmihai :

> Hi,
>
> I have a problem running this code:
>
> import groovy.transform.CompileStatic
> import java.util.function.Function
>
> @CompileStatic
> class Test {
> static void main(String[] args) {
>// this code fails
> Function fct = { Integer n ->
> -n
> }
>
> // this one works but it is too verbose
> // Function fct = ({ Integer n ->
> //  -n
> // } as Function)
>
> println fct.apply(10)
> }
> }
>
> The error:
>
> Test.groovy: 9: [Static type checking] - Incompatible generic argument
> types. Cannot assign java.util.function.Function  groovy.lang.Closure> to: java.util.function.Function 
>  @ line 9, column 36.
> Function fct = { Integer n ->
>   ^
> 1 error
>
> [Finished in 0.5s]
>
> Is there a bug in groovy related to @CompileStatic or maybe I am missing
> something else? I just don't want to write redundant code.
>
> Thanks,
> Mihai
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Static-type-checking-tp5735162.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>

Re: @compileStatic and groovy.sql

[Cédric Champeau]

For type safe sql those days I would recommend to use jOOQ.
Le 23 juin 2016 06:58, "Wilson MacGyver"  a écrit :

> Ouch I will continue to embrace dynamic then :)
>
> On Wed, Jun 22, 2016 at 1:56 PM Guillaume Laforge 
> wrote:
>
>> Perhaps a custom type checker extension could be fed with the jdbc
>> metadata...
>> Le 22 juin 2016 7:41 PM, "Shil Sinha"  a écrit :
>>
>>> Hi Marc,
>>>
>>> You could use the map access syntax i.e. foo['id'] instead and
>>> cast/coerce the result to the appropriate type.
>>>
>>> On Wed, Jun 22, 2016 at 1:37 PM Wilson MacGyver 
>>> wrote:
>>>
 Hi,

 If I want to use compileStatic with groovy.sql, how would I do that?


 the problem as far as I can tell is

 sql.eachRow("select id, from whatever") { foo ->
 ...
   foo.id
 }

 returns data that is known at runtime

 but at compile time. there is no way to know that the SQL statement
 returns a
 id column.

 is there a way to do it?

 Thanks,
 Mac

 --
 Omnem crede diem tibi diluxisse supremum.

>>>

Re: Is it possible to enable CompileStatic for an entire project

[Cédric Champeau]

Or use `@CompileDynamic` on your specs (that's the idea). But in any case,
the IDE will never interpret the script configuration file, so it won't
know that your classes are statically compiled, so won't show you the
proper errors.

2016-06-21 19:03 GMT+02:00 Mario Garcia <mario.g...@gmail.com>:

> If I'm not wrong, projects like Spock doesn't like @CompileStatic so in
> case I would like to statically compile my project, at least I should be
> telling the compiler not to compile statically my specifications. Something
> like:
>
> withConfig(configuration) {
> source(unitValidator: { unit -> !unit.AST.classes.any {
> it.name.endsWith('Spec') } }) {
> ast(CompileStatic)
> }
> }
>
> my two cents
> Mario
>
> 2016-06-21 18:44 GMT+02:00 Cédric Champeau <cedric.champ...@gmail.com>:
>
>> A strong -1 for both options. We already have 2 variants of Groovy today,
>> indy and non indy, and in practice *nobody uses the invokedynamic version*
>> because it's impractical to use. Typically projects depend on `groovy.jar`
>> or `groovy-all.jar`, not their invokedynamic version. Adding a new
>> dimension, which is orthogonal to invokedynamic makes it even more
>> complicated. Don't forget that the Groovy compiler is also mixed in its
>> runtime (which is a problem of its own). We should solve that first.
>>
>> Second, IDEs need to know whether a file is statically compiled or not.
>> The `@CompileStatic` annotation makes it very clear, and the default is the
>> standard dynamic mode that has been in Groovy for more than 10 years. IDEs
>> know about it, and it's simple to infer. Any alternative solution, like the
>> config script, or an alternate compiler (!) makes it impossible for the IDE
>> to guess. The only IDE-pragmatic solution is to have a distinct file
>> extension for statically compiled Groovy files (say, .sgroovy instead of
>> .groovy). So far this has been ruled out, but I think it's the most
>> pragmatic, and IDE friendly, solution.
>>
>>
>>
>> 2016-06-21 18:37 GMT+02:00 Mr Andersson <mr.andersson@gmail.com>:
>>
>>>
>>>
>>> On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
>>>
>>> Tying Cédric’s advice to your previous question about gmavenplus and
>>> joint compilation, per
>>> https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script
>>> you add the configuration tag with a reference to your groovy script.
>>>
>>> I also mentioned that I could not get Gmavenplus to work, but maybe i
>>> did something wrong. But I literally copied and pasted that section.
>>>
>>>
>>>
>>> Actually about 90+% of our code base in Groovy is CompileStatic I wonder
>>> if we should use that. Cédric, if we use the config script method, is it
>>> still possible to use the “skip” annotation to switch back to dynamic mode?
>>> Even if it worked, I highly doubt IntelliJ IDEA would know about it and
>>> think all files are dynamic typing so probably it’s still best for us to
>>> add @CompileStatic everywhere, but sometimes we forget where we wanted it.
>>> The performance difference is extreme when we forget it, on a certain class
>>> we missed recently it took our page rendering times from about 4ms to 52ms,
>>> so for us it’s an actual “bug” to forget to add @CompileStatic.
>>>
>>>
>>> The problem with  the ANT task is that I don't think I can set classpath
>>> argumetns to the actual so passing the config location is a problem that
>>> needs be resolved. Not that easy with maven.
>>>
>>> *Groovy should instead provide a default GroovyStatic-2.4.4.jar* file
>>> that enables this by default. That way everybody wins, and Groovy could
>>> join the club of static languages and not get rejected by those that needs
>>> to get Groovy.
>>>
>>> It is also messy to set up config files for every maven module, although
>>> I am not sure. The code in that config file is also not dynamic.
>>>
>>> withConfig(configuration) { ast(groovy.transform.CompileStatic) } and a
>>> simple option -compileStatic that uses an internal version of that file is
>>> preferable and *SIMPLER*.
>>>
>>> groovyc -configscript src/conf/config.groovy src/main/groovy/MyClass.groovy
>>>
>>> Is not needed here.
>>>
>>>
>>>
>>>
>>> Jason
>>>
>>>
>>>
>>> *From:* Cédric Champeau [mailto:cedric.champ...@gmail.com
>>> <cedric.champ...@gmail.com>]
>>

Re: Is it possible to enable CompileStatic for an entire project

[Cédric Champeau]

It's in the docs:
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

2016-06-21 14:24 GMT+02:00 Mr Andersson :

> Is it possible to enable CompileStatic for an entire project?
>
> Or do you have to do it on a per class basis?
>
> I like Groovy for some of it's features, and mostly for it's close to Java
> syntax but I would really like it to be a static language.
>
> I've heard about Groovy++ but I believe that's dead by now, no?
>
> Question is wether you can tell the Groovy compiler with a flag to treat
> all Groovy classes on certain paths as static?
>
> Preferable doable from ANT too.
>
>
>

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 <tibokr...@googlemail.com>:

> Creating a static Groovy DSL even as a mere unofficial experimental
> branch for now may help improve the level1 API and prevent too much
> functionality from moving into level 2. This is generally beneficial,
> because there is no telling what way Kotlin will go (e.g. sliding into
> a Python2/3 incompatibility scenario). It's easy to get excited about
> unconventional language features, but if anything, the current
> situation shows the technical debt that accumulates when moving away
> from mere java in any API.
>
> Regarding Closures, I guess there are also 3rdparty plugins with
> methods accepting Object, List, Array, and Clojure, trying to do
> polymorphism without interfaces. Not sure how much core gradle has
> that, but the plugin landscape is also vast indeed.
>
> At the time I wrote my own gradle plugin, I did need some horrible casting:
>
> https://github.com/tkruse/gradle-groovysh-plugin/blob/master/src/main/groovy/com/tkruse/gradle/groovysh/DynamicInvokeHelper.groovy
> not sure how much of it could be cleaned up now, but I want to stay
> backwards compatible anyway, so a better new API only helps so much.
>
>
> On Mon, May 23, 2016 at 10:05 PM, Cédric Champeau
> <cedric.champ...@gmail.com> wrote:
> > Basically, some of the Gradle core classes are still using `Closure` as a
> > last parameter, which doesn't make them usable in Java, Kotlin, or
> > statically compiled Groovy. For a long time now, those methods are being
> > replaced in Gradle by "language agnostic" interfaces: Action
> instead of
> > Closure (which is related to the thread I launched a few days ago about
> > delegation strategy for automatic closure coercion). This is the absolute
> > minimal thing that Java needs, Kotlin needs, and to some extent static
> > Groovy need so that we can write plugins in those languages without
> relying
> > on very dirty code (new Closure(this) { ...insert some casts and
> reflective
> > code here... }).
> >
> > This is the "level 1" api. But it doesn't make a new static DSL. The
> layer 2
> > is language specific. Kotlin will use extension methods, static builders,
> > ... while my experiment in Groovy uses extension modules. So when we
> work on
> > level 1, we're improving the experience for all static languages, and
> that
> > allows each language to put its own DSL layer on top of that. Kotlin
> first.
> > There's no plan for a static Groovy DSL at Gradle for now (this could
> > change), for the reasons I explained in my blog post (IDE support,
> duplicate
> > work, ...).
> >
> > 2016-05-23 14:27 GMT+02:00 Thibault Kruse <tibokr...@googlemail.com>:
> >>
> >> > 2016-05-23 13:59 GMT+02:00 Thibault Kruse <tibokr...@googlemail.com>:
> >> >>
> >> >> It would be more interesting to investigate whether Gradle could
> >> >> provide a programmatic API that allows easily using any JVM language
> >> >> to define builds.
> >> On Mon, May 23, 2016 at 9:05 PM, Cédric Champeau
> >> <cedric.champ...@gmail.com> wrote:
> >> > Thibault, this is exactly what Gradle is doing. ...
> >>
> >> In that case, there are two possibilitities. Either in all the
> >> documentation, both Groovy and Kotlin will use the new, improved API.
> >> Which probably implies lack of backwards compatibility, so all
> >> build.gradle scripts have to be adapted when upgrading.
> >>
> >> Or, Kotlin will use the new improved API in the documentation, whereas
> >> the Groovy examples will keep the old API, meaning the old API is also
> >> available from Kotlin (causing mess and confusion).
> >>
> >> Could you clarify that?
> >>
> >>
> >>
> >>
> >>
> >> On Mon, May 23, 2016 at 9:05 PM, Cédric Champeau
> >> <cedric.champ...@gmail.com> wrote:
> >> > Thibault, this is exactly what Gradle is doing. The Kotlin support is
> >> > the
> >> > occasion to provide better APIs that are more friendly to static
> >> > languages.
> >> > In my post I have shown an example of the static Groovy version. The
> >> > question is not whether we can do it or not. We can do it. The issue
> is
> >> > IDE
> >> > support. Have this scripts recognized by the IDE as such. Have a
> decent
> >

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

[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: Expando as a Trait?

[Cédric Champeau]

I think what you are suggesting is close to this example in the docs:
http://groovy-lang.org/objectorientation.html#_dynamic_methods_in_a_trait

Am I right?

2016-03-18 16:51 GMT+01:00 Gerald Wiltse :

> Expando is a pretty cool object. And if we extend it, we get it's really
> nice "behavior". Unfortunately, as extending = inheritance, thus extending
> expando precludes us from extending our true parent classes. This is why
> implementing interfaces and traits is often a better choice than
> inheriting, especially when one just wants to compose behaviors such as
> those offered by expando.
>
> Which leads me to ask the question: is it crazy to suggest that the body
> of Expando would actually make a good Trait?   Has this been discussed
> before?
>
> I'm novice so there could be obvious reasons not to do this which I'm not
> aware of.
>
>
> Gerald R. Wiltse
> jerrywil...@gmail.com
>
>

Re: problem accessing class method from FileTreeBuilder in a closure

[Cédric Champeau]

I noticed exactly this a few days ago. The builder interprets the call as
internal. As a workaround you can prefix the class method with "this.":
this.testData().


2016-03-11 13:29 GMT+01:00 bartoleo :

> Hi I'm using FileTreBuilder to create ten dirs with a file in it, the
> content
> is returned by a class method.
>
> Here is an example:
>
> class MyFileTreeBuilder {
>
>   static def testData(){
> "my test data..."
>   }
>
>   static void main(String[] args) {
>
> def tree = new FileTreeBuilder()
> 10.times{index->
>   tree.dir("tests/test${index}"){
> file "test.txt", testData()
>   }
>   println(new File("tests/test${index}/test.txt").text)
> }
>
>   }
>
> }
>
> It seems that FileTreeBuilder cannot find my class method if used in a
> closure. (it works correctly if I remove the '10.times...'
>
> Could it be a bug?
>
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/problem-accessing-class-method-from-FileTreeBuilder-in-a-closure-tp5731840.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>

Re: TypeChecked with apache commons Pair cannot find matching method

[Cédric Champeau]

You absolutely need to call the one that takes a Class as an argument. The
String version is really for deep internal things, and can be resolved by
the compiler, but it's already too late in an AST xform.

2016-02-22 12:39 GMT+01:00 Anton Sarov <izvanz3mn...@yahoo.com>:

> But now that you mention it... I see that there is some big difference in
> ClassHelper.make(String) and ClassHelper.make(Class) - regarding generics,
> ClassNode construction and similar.
> If I use the overriden method with a Class argument then the error is
> gone. But I am still slightly confused as why the different behavior?
>
> Best regards
> Anton
>
>
> On Monday, February 22, 2016 12:30 PM, Anton Sarov <izvanz3mn...@yahoo.com>
> wrote:
>
>
> Hi Cedric,
>
> well first in the method where I transform the MethodCallExpression I use
> this: ClassHelper.make(returnType) where 'returnType' is the String
> "org.apache.commons.lang3.tuple.Pair" and after this in my
> visitDeclarationExpression (as I am in a Visitor) I use this ClassNode to
> create the CastExpression.
>
> Best regards
> Anton
>
>
> On Monday, February 22, 2016 12:09 PM, Cédric Champeau <
> cedric.champ...@gmail.com> wrote:
>
>
> Hi Anton!
>
> How, in your AST transformation, do you create the class node for `Pair`?
>
>
>
> 2016-02-22 12:02 GMT+01:00 Anton Sarov <izvanz3mn...@yahoo.com>:
>
> Hello,
>
> I have a DSL and some AST transformations. Now I would like to include
> some 3rd party classes in my DSL. For example some apache commons lang
> classes like Pair, etc.
>
> In my language I offer the user the "bar()" method (which I have defined
> elsewhere). However the "bar()" method is just for user's convenience.
> Actually I am calling the "bar2()" method under the hood - this is why I
> have the AST transformation.
>
> So writing:
>
> def foo = bar()
>
> Becomes:
>
> def foo = bar2() as Pair
>
> Now consider this AFTER transformation statement:
>
> def foo = bar2() as Pair
> foo.getKey()
> foo.getValue()
>
> Having the @TypeChecked annotation I get this error: Cannot find matching
> method org.apache.commons.lang3.tuple.Pair#getKey(). Please check if the
> declared type is right and if the method exists.
>
> But if I write something like:
>
> def foo = Pair.of(3,4)
> foo.getKey()
> foo.getValue()
>
> Then everything is fine. Is there something that I am missing. What is
> even more weird: I have my Type Checker extension and I see that
> "handleMissingMethod" is called for "foo.getKey()" so at this point I try
> to resolve the statement by myself but calling "...getDeclaredMethods(..)"
> returns an empty list.
>
> Best regards
> Anton
>
>
>
>
>
>
>

Re: TypeChecked with apache commons Pair cannot find matching method

[Cédric Champeau]

Hi Anton!

How, in your AST transformation, do you create the class node for `Pair`?



2016-02-22 12:02 GMT+01:00 Anton Sarov :

> Hello,
>
> I have a DSL and some AST transformations. Now I would like to include
> some 3rd party classes in my DSL. For example some apache commons lang
> classes like Pair, etc.
>
> In my language I offer the user the "bar()" method (which I have defined
> elsewhere). However the "bar()" method is just for user's convenience.
> Actually I am calling the "bar2()" method under the hood - this is why I
> have the AST transformation.
>
> So writing:
>
> def foo = bar()
>
> Becomes:
>
> def foo = bar2() as Pair
>
> Now consider this AFTER transformation statement:
>
> def foo = bar2() as Pair
> foo.getKey()
> foo.getValue()
>
> Having the @TypeChecked annotation I get this error: Cannot find matching
> method org.apache.commons.lang3.tuple.Pair#getKey(). Please check if the
> declared type is right and if the method exists.
>
> But if I write something like:
>
> def foo = Pair.of(3,4)
> foo.getKey()
> foo.getValue()
>
> Then everything is fine. Is there something that I am missing. What is
> even more weird: I have my Type Checker extension and I see that
> "handleMissingMethod" is called for "foo.getKey()" so at this point I try
> to resolve the statement by myself but calling "...getDeclaredMethods(..)"
> returns an empty list.
>
> Best regards
> Anton
>

[ANN] Apache Groovy 2.4.6

[Cédric Champeau]

Dear community,

We are pleased to announce the release of Apache Groovy 2.4.6! Apache
Groovy is a multi-facet programming language for the JVM. Details can be
found at http://groovy-lang.org

This release is a maintenance release of the 2.4.x branch.

Changelog for this version can be found at:
http://groovy-lang.org/changelogs/changelog-2.4.6.html
Sources can be downloaded from: http://www.groovy-lang.org/download.html
Convenience binaries, SDK and documentation can be found at:
http://www.groovy-lang.org/download.html and Maven Central.

We would like to thank all people who contributed to this release, the
first one since we went top-level! Keep the contributions going, and be
prepared for a 2.5.0-beta release soon!

Best regards,

Cédric, on behalf of the Apache Groovy team

Re: GroovyShell Binding with TypeChecked

[Cédric Champeau]

Hi Anton,

First of all, your code is invalid even without @TypeChecked. I guess what
you want is to execute a *script* at runtime, that uses a TypeChecked class
that is precompiled. It means that you have 2 conflicting timelines. The
first one is what happens when you compile the class you want to make
available to scripts, and the second is what happens when the script itself
is compiled (at runtime). You have to ask yourself: what does the type
checker knows when it compile your class, vs what *you* know when your code
is executed. Be a machine, and look at your code: when A is compiled, the
compiler knows *nothing* about "util". It's only because you, as a
developer, know that "util" is going to be provided by the binding, that
you, as a developer, can infer the type of that variable (and in practice,
since your code is wrong, "util" wouldn't be visible anyway because it's
used in a class scope, not in a script, but let's forget about that).

To illustrate this, you can totally imagine that your binding is going to
be modified during execution of the script. One could write "util = new
Date()", and the compiler would be totally wrong. That's why, you, as a
developer, have to help the compiler, to tell it that actually *you* know
that the type of "util" is, because you will provide it through the
binding, or through a super script class, or  That's what type checking
extensions are meant for. I'd recommend that you read the appropriate
section in the userguide

.



2016-02-04 10:10 GMT+01:00 Anton Sarov :

> Hi Pascal,
>
> I realize that the binding is just a map but I still do not see the
> implication. The type checker could very well take the variable name - in
> my case "util" and look it up in the map/binding - just to see if there is
> such a key.
>
> Now I am having the feeling that the type checker does not use the
> binding/map at all. Am I correct?
>
> Best regards
> Anton
>
>
> On Wednesday, February 3, 2016 10:43 PM, Pascal Schumacher <
> pascalschumac...@gmx.net> wrote:
>
>
> Hi Anton,
>
> Binding is essentially just a map. The typ checker does not know which
> values will be present. Therefore it flags "util" as undeclared.
>
> Cheers,
> Pascal
>
> Am 03.02.2016 um 16:24 schrieb Anton Sarov:
>
> Hello,
>
> I have the following case where I want to make use of the type checking
> feature:
>
> 
> http://groovyconsole.appspot.com/script/5121843795066880
>
>
> Unfortunately I get an error like: "The variable [util] is undeclared".
>
> Why is this happening? I defined a variable in the provided binding but
> apparently this is somehow not relevant to the Groovy Shell...
>
> Best regards
> Anton
>
> startup failed:
> Script1.groovy: 7: [Static type checking] - The variable [util] is undeclared.
>  @ line 7, column 17.
>def a = util.test();
>^
>
> 1 error
>
> startup failed:
> Script1.groovy: 7: [Static type checking] - The variable [util] is undeclared.
>  @ line 7, column 17.
>def a = util.test();
>^
>
> 1 error
>
> startup failed:
> Script1.groovy: 7: [Static type checking] - The variable [util] is undeclared.
>  @ line 7, column 17.
>def a = util.test();
>^
>
> 1 errorstartup failed:
> Script1.groovy: 7: [Static type checking] - The variable [util] is undeclared.
>  @ line 7, column 17.
>def a = util.test();
>^
>
> 1 error
>
> startup failed:
> Script1.groovy: 7: [Static type checking] - The variable [util] is undeclared.
>  @ line 7, column 17.
>def a = util.test();
>^
>
> 1 error
>
>
>
>
>

Re: Groovy Beta

[Cédric Champeau]

Fixes should almost always be backported, unless there's a good reason not
to (for example, backporting means rewriting part of the fix). If it's not
the case, then it's a mistake. I have not been capable of checking if the
recent fixes on master have been systematically backported, but they
should. So hopefully this is just JIRA not up-to-date.

2016-01-15 21:13 GMT+01:00 Winnebeck, Jason 
:

> Sorry, I wasn't clear. By snapshot I meant a declaration/tag by the
> developers. For example when Groovy team releases 2.5.0-beta1, not only is
> it something I can explain globally "we are using 2.5.0-beta1 and see xyz",
> but it also means that the team is saying the code is in a reasonable state
> for someone to use (i.e. there's not a major refactor in progress -- for
> example I have no clue if 2.5.0 being a new feature branch has a refactor
> going on).
>
> Anyway, knowing about the snapshot builds is useful as I can eliminate any
> potential mistake in my build process. I will try that snapshot JAR Monday
> to verify the fix for GROOVY-7705 for our application.
>
> I apologize about the side-tracked conversation, initially I only meant to
> ask whether or not a release was soon to know if I should go through the
> effort of validating a nightly for a production system. Since 2.5 beta is
> not soon, the only open question left for me is if GROOVY-7705 could be
> backported into 2.4.6 or at least 2.4.x (I'd feel safer with a
> 2.4.7-SNAPSHOT than 2.5.0-SNAPSHOT). I asked that in the JIRA.
>
> -Original Message-
> From: Pascal Schumacher [mailto:pascalschumac...@gmx.net]
> Sent: Friday, January 15, 2016 2:54 PM
> To: users@groovy.apache.org
> Subject: Re: Groovy Beta
>
> Hi Jason,
>
> you do not have to build it yourself if you want to validate a snapshot.
>
> You can add https://oss.jfrog.org/artifactory/oss-snapshot-local/ as a
> maven repo and pull 2.5.0-SNAPSHOT from there.
>
> -Pascal
>
> Am 15.01.2016 um 20:46 schrieb Winnebeck, Jason:
> > I have built Groovy on my home machine successfully, it is not bad at
> all. However, I'm working on a large enterprise app, so it is nice to at
> least have some form of snapshot in time. So, I can deploy it to our local
> Maven repository under different group ID, but then I still have the
> uncertainty of pulling the latest code and not even knowing if there is a
> half-finished task or refactor going on in there, whereas with a "blessed"
> beta the team is saying they think the code is clean. I could validate the
> "tip" works in our app but that is not productive if a release is coming
> soon. There's also the awkward-ness of having a custom-built Groovy
> not-quite-2.4 but not-quite-2.5 version out and about. However, the fix is
> big enough for me that if it doesn't make it into the recent 2.4.6 release,
> I may very well go through the effort to build the tip of beta branch and
> validate.
> >
> > Jason
> >
> > -Original Message-
> > From: Russel Winder [mailto:rus...@winder.org.uk]
> > Sent: Friday, January 15, 2016 2:29 PM
> > To: users@groovy.apache.org
> > Subject: Re: Groovy Beta
> >
> > On Fri, 2016-01-15 at 19:05 +, Winnebeck, Jason wrote:
> >> A Groovy issue that affects us significantly was recently fixed in
> >> the Apache JIRA as "2.5.0-beta1". From what I can tell, there is not
> >> currently a place to download betas. Is there a plan to release a
> >> Groovy 2.5 beta milestoon soon?
> > Probably not. I compile and install from source. Takes about 22 mins on
> my workstation (which is 9 years old so I expect modern kit to do better).
> >
> > --
> > Russel.
> >
> =
> > Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
> >
> >
> > --
> > This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>
>