[ANNOUNCE] Apache Groovy 3.0.0-beta-1 Released

2019-05-10 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 3.0.0-beta-1 of
Apache Groovy.
Apache Groovy is a multi-faceted programming language for the JVM.
Further details can be found at the https://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 109 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344761

Sources, convenience binaries, downloadable documentation and an SDK
bundle can be found at: https://groovy.apache.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.


[ANNOUNCE] Apache Groovy 2.5.7 Released

2019-05-10 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.7 of Apache Groovy.
Apache Groovy is a multi-faceted programming language for the JVM.
Further details can be found at the https://groovy.apache.org website.

This release is a maintenance release of the GROOVY_2_5_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 56 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344939

Sources, convenience binaries, downloadable documentation and an SDK
bundle can be found at: https://groovy.apache.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.


[ANNOUNCE] Apache Groovy 2.4.17 Released

2019-05-10 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.4.17 of Apache Groovy.
Apache Groovy is a multi-faceted programming language for the JVM.
Further details can be found at the https://groovy.apache.org website.

This release is a maintenance release of the GROOVY_2_4_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 5 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12345028

Sources, convenience binaries, downloadable documentation and an SDK
bundle can be found at: https://groovy.apache.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: GroovyDoc classloader issue

2019-05-07 Thread Paul King
Hi Alexey, I managed to replicate using your code - thanks. But I didn't
have time yet to see if I could come up with a way to implement your
suggestion in a backward compatible way. Is there a Jira for the issue yet?
Please create one if not.

Cheers, Paul.

On Tue, May 7, 2019 at 7:16 PM Alexey Belostotskiy  wrote:

> Hi,
> Did you get a chance to test it?
>
> 26.02.2019, 00:24, "Paul King" :
>
> Hi Alexey, the attachment came through. I just haven't had time to test it
> yet. Thanks!
>
> Cheers, Paul.
>
> On Tue, Feb 26, 2019 at 1:20 AM Alexey Belostotskiy 
> wrote:
>
> Hi, did you receive the last email (with test in attachment)? I'm not sure
> if it was sent properly.
>
> 20.02.2019, 17:34, "Alexey Belostotskiy" :
>
> Hi, it's kind of messy, but I hope you'll get the idea.
>
> 19.02.2019, 23:48, "Paul King" :
>
> Our preference would be to have a standalone testcase that triggers your
> problem. Are you in a position to create such a test?
>
> On Wed, Feb 20, 2019 at 1:24 AM Alexey Belostotskiy 
> wrote:
>
> Hello,
>
> We're generating groovydocs in runtime in our app. We use groovydoc as a
> library, not standalone tool.
>
> It mostly works, but we're experiencing issues with some classes ending up
> unresolved. I found out that this happens because SimpleGroovyClassDoc is
> calling its getClass().getClassLoader() to get classloader for class
> resolution. But in our case, most of classes that we want to link should be
> loaded via different classloader.
>
> Basically, solution that would work for us, is to replace
> getClass().getClassLoader() calls in SimpleGroovyClassDoc with
> Thread.currentThread().getContextClassLoader(), but that might be a
> breaking change.
>
> I'm not sure what the process is for requesting such changes and whether
> it's something that Groovy team is willing to implement.
>
>


Re: Static imports seem to win over a method in closure's delegate

2019-04-12 Thread Paul King
Using import aliases can be a good workaround for such a case.

On Sat, Apr 13, 2019 at 4:58 AM Jochen Theodorou  wrote:

> On 10.04.19 16:05, Herrendorf Johannes wrote:
> > Hi Groovy users,
> >
> > I’m currently building a DSL in groovy and found some strange behaviour
> > I have no explanation for: If a method pointer with name "myMethod" is
> > imported as static import and a closure has a delegate with a method
> > "myMethod" and it's delegation strategy is set to "DELEGATION_ONLY", the
> > imported method is always called inside the closure - the delegate
> > property seems to be ignored.
>
> two things to always remember:
> * closure delegation is a runtime mechanism, it has no influence on
> static compiled features
> * static imports are compiled statically
>
> The later is not because we want this, but because we have to more or
> less. And it is painful. I can imagine a system where this is not
> required, but that is far from easy or efficient.
>
> [...]
> > import static mailinglist.SomeOtherClass.myMethod
> [...]
> >   // dispatched to SomeOtherClass.myMethod; correct
> >  myMethod "Hello"
> >  closureStuff {
> >  // dispatched to SomeOtherClass.myMethod, but I expected
> that
> >   // it's dispatched to ClosureDelegate.myMethod
> instead
> >  myMethod "Good Morning"
> >  }
> [...]
> > Am I missing something or is this a bug? Thanks for your help in advance!
>
> In short it is a limitation. I am not sure we can really do something
> against that.
>
> bye Jochen
>
>


Re: groovy.text.markup.MarkupTemplateEngine issue since 2.5.3

2019-03-29 Thread Paul King
Hi,

It does look vaguely familiar as a regression we are currently looking into
related to "train wreck" style expressions, e.g. "a.b.c.d.e", inside nested
closures.
The workaround might be to simplify your expressions until we get that
fixed. There are a couple of related issues but none exactly match the
symptoms as you describe them.
If you can tease out a reproducer, that would be great as another testcase
as we work on that area. You could just create a separate issue and if we
can merge later, we'll do that.

Cheers, Paul.


On Fri, Mar 29, 2019 at 8:14 PM Arnaud Yahoo  wrote:

> Hello,
>
> I am using MarkupTemplateEngine to generate some html pages
>
> Until I used groovy 2.5.2 everything was working but since I upgraded to
> 2.5.6 it start failing with stack trace given above.
>
> It tried with several versions and it start failing with 2.5.3.
>
> I am trying to reproduce this with a simple sample (my generation code
> is quite complex), in the meantime, does this
> "groovy.lang.MissingPropertyException: No such property: implicitThis
> for class: org.codehaus.groovy.ast.expr.StaticMethodCallExpression"means
> something to someone ?
>
> groovy.lang.MissingPropertyException: No such property: implicitThis for
> class: org.codehaus.groovy.ast.expr.StaticMethodCallExpression
>  at
>
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:65)
>  at
>
> org.codehaus.groovy.runtime.callsite.GetEffectivePojoPropertySite.getProperty(GetEffectivePojoPropertySite.java:65)
>  at
>
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:298)
>  at
>
> groovy.text.markup.MarkupTemplateTypeCheckingExtension$_run_closure3.doCall(MarkupTemplateTypeCheckingExtension.groovy:127)
>  at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>  at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
>  at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
>  at
>
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:263)
>  at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
>  at groovy.lang.Closure.call(Closure.java:405)
>  at
>
> org.codehaus.groovy.transform.stc.AbstractTypeCheckingExtension.safeCall(AbstractTypeCheckingExtension.java:183)
>  at
>
> org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.handleMissingMethod(GroovyTypeCheckingExtensionSupport.java:357)
>  at
>
> org.codehaus.groovy.transform.stc.DefaultTypeCheckingExtension.handleMissingMethod(DefaultTypeCheckingExtension.java:114)
>  at
>
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitStaticMethodCallExpression(StaticTypeCheckingVisitor.java:2540)
>  at
>
> org.codehaus.groovy.ast.expr.StaticMethodCallExpression.visit(StaticMethodCallExpression.java:43)
>  at
>
> org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:120)
>  at
>
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:197)
>  at
>
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
>  at
>
> org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
>  at
>
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:106)
>  at
>
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBlockStatement(StaticTypeCheckingVisitor.java:3771)
>  at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
>  at
>
> org.codehaus.groovy.ast.CodeVisitorSupport.visitClosureExpression(CodeVisitorSupport.java:225)
>  at
>
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClosureExpression(StaticTypeCheckingVisitor.java:2322)
>  at
>
> org.codehaus.groovy.ast.expr.ClosureExpression.visit(ClosureExpression.java:46)
>  at
>
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallArguments(StaticTypeCheckingVisitor.java:2632)
>  at
>
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:3466)
>  at
>
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:397)
>  at
>
> org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:68)
>  at
>
> org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:120)
>  at
>
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:197)
>  at
>
> 

Re: groovyscript and binding, what is wrong in this code

2019-03-20 Thread Paul King
I should have also mentioned that you don't need to even use evaluate if
you don't want. I'd suggest using @Field in that case:

import groovy.transform.Field

@Field zebra_test1_list = [ "zebra1", "zebra2" ]
@Field zebra_test2_list = [ "zebra3", "zebra4" ]

def zebras = (1..2).collect {
   this."zebra_${'test' + it}_list"
}

assert zebras == [['zebra1', 'zebra2'],
  ['zebra3', 'zebra4']]

Cheers, Paul.


On Thu, Mar 21, 2019 at 10:00 AM Paul King  wrote:

> You probably want to use the binding and just normal script evaluate rather
> than
> Eval.me which is designed for when you don't want the full binding.
>
> zebra_test1_list = [ 'zebra1', 'zebra2' ]
> zebra_test2_list = [ 'zebra3', 'zebra4' ]
>
> def zebras = (1..2).collect {
> evaluate("zebra_${'test' + it}_list")
> }
>
> assert zebras == [['zebra1', 'zebra2'],
>   ['zebra3', 'zebra4']]
>
> Note that there is no def for the first two lines, otherwise
> you are defining local variables which are normally visible
> but not within the new context created when using evaluate.
>
> Cheers, Paul.
>
>
> On Thu, Mar 21, 2019 at 8:23 AM Narahari Lakshminarayana <
> itsme.narah...@gmail.com> wrote:
>
>> Friends:
>>
>> Thank you in advance for your help.
>>
>> I have the following groovyscript code.
>>
>> def zebra_test1_list = [ "zebra1", "zebra2" ]
>> def zebra_test2_list = [ "zebra3", "zebra4" ]
>>
>> def data="test1"
>> def zebra = groovy.util.Eval.me("zebra_${data}_list")
>>
>> println zebra
>>
>>
>> I get the error
>>
>> groovy> def zebra_test1_list = [ "zebra1", "zebra2" ]
>> groovy> def zebra_test2_list = [ "zebra3", "zebra4" ]
>> groovy> def data="test1"
>> groovy> def zebra = groovy.util.Eval.me("zebra_${data}_list")
>> groovy> println zebra
>>
>> Exception thrown
>>
>> groovy.lang.MissingPropertyException: No such property: zebra_test1_list
>> for class: Script1
>> at Script1.run(Script1.groovy:1)
>> at ConsoleScript2.run(ConsoleScript2:5)
>>
>>
>> Please help as to what I might be doing wrong.
>>
>> -N
>>
>


Re: groovyscript and binding, what is wrong in this code

2019-03-20 Thread Paul King
You probably want to use the binding and just normal script evaluate rather
than
Eval.me which is designed for when you don't want the full binding.

zebra_test1_list = [ 'zebra1', 'zebra2' ]
zebra_test2_list = [ 'zebra3', 'zebra4' ]

def zebras = (1..2).collect {
evaluate("zebra_${'test' + it}_list")
}

assert zebras == [['zebra1', 'zebra2'],
  ['zebra3', 'zebra4']]

Note that there is no def for the first two lines, otherwise
you are defining local variables which are normally visible
but not within the new context created when using evaluate.

Cheers, Paul.


On Thu, Mar 21, 2019 at 8:23 AM Narahari Lakshminarayana <
itsme.narah...@gmail.com> wrote:

> Friends:
>
> Thank you in advance for your help.
>
> I have the following groovyscript code.
>
> def zebra_test1_list = [ "zebra1", "zebra2" ]
> def zebra_test2_list = [ "zebra3", "zebra4" ]
>
> def data="test1"
> def zebra = groovy.util.Eval.me("zebra_${data}_list")
>
> println zebra
>
>
> I get the error
>
> groovy> def zebra_test1_list = [ "zebra1", "zebra2" ]
> groovy> def zebra_test2_list = [ "zebra3", "zebra4" ]
> groovy> def data="test1"
> groovy> def zebra = groovy.util.Eval.me("zebra_${data}_list")
> groovy> println zebra
>
> Exception thrown
>
> groovy.lang.MissingPropertyException: No such property: zebra_test1_list
> for class: Script1
> at Script1.run(Script1.groovy:1)
> at ConsoleScript2.run(ConsoleScript2:5)
>
>
> Please help as to what I might be doing wrong.
>
> -N
>


shell scripts tweaks

2019-03-17 Thread Paul King
Hi folks,

Thanks to a contribution from Dylan Cali, the startup shell scripts
have been tweaked to be shellcheck[1] compliant. We have done a
bit of manual testing but if anyone (especially any cygwin/msys users)
wants to do more extensive checks that everything is behaving as
expected, that would be great.

No changes were done to windows .bat files.

I plan to incorporate that change into 2.5.7 in a few days time
if I don't get any further feedback.

Cheers, Paul.

[1] https://github.com/koalaman/shellcheck


Re: Friends of Groovy Open Collective

2019-03-12 Thread Paul King
We are following the open collective policy where core committers (of the
collective) are the ones who can approve expense submissions. I expect we
will grow the number of core committers over time. At some point, I imagine
it would be nice to describe a process for deciding fees/bounties and
prioritisation of potential tasks but most collectives don't seem to do
this (if you spot any good examples, let us know).

In terms of conflicts of interest between the Open Collective and Apache
sides of the world, any code/doco/etc created by the collective has to be
fed into the Apache Groovy project in the normal way. The normal diversity
of the Apache Groovy PMC should come into play in that case. For
contentious issues, it might be appropriate for a PMC member to opt out of
voting on the Apache side or opt out of direct involvement on the
collective side. I imagine such cases would be very rare but we need to
remain aware of that possibility.

Or did you have something else in mind that you think we need to address up
front?

Cheers, Paul.


On Wed, Mar 13, 2019 at 4:42 AM Cédric Champeau 
wrote:

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


Friends of Groovy Open Collective

2019-03-07 Thread Paul King
Hi everyone,

As an independent initiative, we have set up an open collective for Groovy:

https://opencollective.com/friends-of-groovy

This initiative is designed to complement the Apache project and the many
contributions we get from our great community and supporters.

Rationale: The Apache Software Foundation values community integrity and
vendor independence very highly. As a general principle, it doesn't accept
"cash for code" so that individual cash payments can't force contributions
into a project which aren't aligned with community consensus. While we
value the existing contributions to the project very highly, we wanted this
complementary mechanism for any supporters out there who aren't in a
position to dedicate their time to the project.

Big kudos to Daniel Sun for spearheading the latest push for this
initiative.

Cheers, Paul.


Re: GroovyDoc classloader issue

2019-02-25 Thread Paul King
Hi Alexey, the attachment came through. I just haven't had time to test it
yet. Thanks!

Cheers, Paul.

On Tue, Feb 26, 2019 at 1:20 AM Alexey Belostotskiy  wrote:

> Hi, did you receive the last email (with test in attachment)? I'm not sure
> if it was sent properly.
>
> 20.02.2019, 17:34, "Alexey Belostotskiy" :
>
> Hi, it's kind of messy, but I hope you'll get the idea.
>
> 19.02.2019, 23:48, "Paul King" :
>
> Our preference would be to have a standalone testcase that triggers your
> problem. Are you in a position to create such a test?
>
> On Wed, Feb 20, 2019 at 1:24 AM Alexey Belostotskiy 
> wrote:
>
> Hello,
>
> We're generating groovydocs in runtime in our app. We use groovydoc as a
> library, not standalone tool.
>
> It mostly works, but we're experiencing issues with some classes ending up
> unresolved. I found out that this happens because SimpleGroovyClassDoc is
> calling its getClass().getClassLoader() to get classloader for class
> resolution. But in our case, most of classes that we want to link should be
> loaded via different classloader.
>
> Basically, solution that would work for us, is to replace
> getClass().getClassLoader() calls in SimpleGroovyClassDoc with
> Thread.currentThread().getContextClassLoader(), but that might be a
> breaking change.
>
> I'm not sure what the process is for requesting such changes and whether
> it's something that Groovy team is willing to implement.
>
>


Re: GroovyDoc classloader issue

2019-02-19 Thread Paul King
Our preference would be to have a standalone testcase that triggers your
problem. Are you in a position to create such a test?

On Wed, Feb 20, 2019 at 1:24 AM Alexey Belostotskiy  wrote:

> Hello,
>
> We're generating groovydocs in runtime in our app. We use groovydoc as a
> library, not standalone tool.
>
> It mostly works, but we're experiencing issues with some classes ending up
> unresolved. I found out that this happens because SimpleGroovyClassDoc is
> calling its getClass().getClassLoader() to get classloader for class
> resolution. But in our case, most of classes that we want to link should be
> loaded via different classloader.
>
> Basically, solution that would work for us, is to replace
> getClass().getClassLoader() calls in SimpleGroovyClassDoc with
> Thread.currentThread().getContextClassLoader(), but that might be a
> breaking change.
>
> I'm not sure what the process is for requesting such changes and whether
> it's something that Groovy team is willing to implement.
>


Re: Groovy file associations on Windows

2019-02-10 Thread Paul King
I'd be inclined to keep GPars in the mix for now. It isn't actively
maintained but is still very useful in its current form and I hope to put
some time into it at some stage.

Cheers, Paul.


On Mon, Feb 11, 2019 at 12:24 PM Keegan Witt  wrote:

> In addition to removing projects that are no longer developed from the
> Groovy Windows installer (Gpars, Gaelyk, Scriptom, EasyB, Gant, GMock), I'm
> considering removing the exe files from groovy-native-launcher
> .  These haven't been
> compiled in quite a while and are just another thing to maintain.  As I see
> it, there are two primary benefits these provide.
>
>1. Provide a way to create file associations so you can double click a
>Groovy file, or run myFile.groovy instead of groovy myFile.groovy.
>2. Hide the command window when launching GroovyConsole.
>
> For #2, I can work around this with a VBScript file (or NirCmd).  #1
> doesn't have a good way to solve other than the current native binary
> solution since Launch4J doesn't support variable expansion
> .  My question is, do many
> folks need this functionality?  It's something I've never personally used.
> Please weigh in with your thoughts.
>
> -Keegan
>


Re: [ANNOUNCE] Groovy 2.5.6 Windows Installer Released

2019-02-08 Thread Paul King
Nice. Thanks Keegan!

On Fri., 8 Feb. 2019, 1:26 pm Keegan Witt  The Windows installer for Groovy 2.5.6 is available from the usual place:
> https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.6-installer
> .
>
> -Keegan
>


Re: AST Transformation Issues

2019-02-05 Thread Paul King
Hi,

With regard to stack overflow when printing. This is a known limitation.
ToString has been made smart enough to handle self references, e.g.

import groovy.transform.*

@ToString
class Tree {
Tree left, right
}

def t1 = new Tree()
t1.left = t1
println t1 // => Tree((this), null)

but isn't smart enough to handle mutual recursion, e.g.:

def t2 = new Tree()
t1.left = t2
t2.left = t1
println t1 // => StackOverflowError

The plan has always been to make it smarter but we haven't done it yet. PRs
welcome.

If anyone is interested, I'd recommend something simple like what we have
done for lists and maps in the respective InvokerHelper methods.
E.g. for maps, self reference is already handled:

def t3 = [:]
t3.with{ left = t3; right = t3 }
println t3 // => [left:(this Map), right:(this Map)]

And mutual reference is handled by setting a maximum size (30 in the
example below and three dots is used once the toString becomes greater than
30 in size):

import org.codehaus.groovy.runtime.InvokerHelper
def t4 = [left: t3]
t3.right = t4
println InvokerHelper.toMapString(t3, 30) // => [left:(this Map),
right:[left:[...]]]

It works so long as the Map contents themselves don't have stack overflow
scenarios that aren't catered for (some scenarios are handled).

Similarly for lists, self reference is handled:

def items = []
3.times{ items << items }
println items // [(this Collection), (this Collection), (this
Collection)]

but you can limit the size (e.g. for the case above) or to handle mutual
reference:

println InvokerHelper.toListString(items, 30) // => [(this Collection),
(this Collection), ...]

def list1 = []
def list2 = []
list1 << list2
list2 << list1
//println list1 // StackOverflowError
println InvokerHelper.toListString(list1, 10) // =>
[[[...]]]

So getting back to @ToString, I'd imagine an enhancement could involve
either generating a toString(int maxSize) method or supporting a maxSize
annotation attribute that was automatically supported in the generated code
for the normal toString method.

With regard to the AutoClone issues, as per the documentation, the
supported cloning styles have various assumptions, e.g. SIMPLE style
assumes child classes are of a similar style (or have equivalent methods),
and the basic styles support only shallow cloning. For your case you want
deep cloning, so SERIALIZATION would be the way to go.

abstract class AbstractEvent {
Date created
String createdBy
Date modified
String modifiedBy
}

@AutoClone(style=SERIALIZATION)
@ToString(includeSuper = true)
class Event extends AbstractEvent implements Serializable {
Long id
String someText
ArrayList subEvents = new ArrayList()
}

@AutoClone(style=CLONE)
@ToString(includeSuper = true, excludes = ['event'])
class SubEvent extends AbstractEvent implements Serializable {
Long id
String someText
Event event
}

Cheers, Paul.






Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Feb 6, 2019 at 7:46 AM Nikolai (gmail) 
wrote:

> Hello,
>
> I experienced some Issues using ToString and AutoClone on Entities (Spring
> JPA).
>
> Both can lead to endless loops / a stackoverflow, when classes reference
> each other.
>
> While it's fine for AutoClone, I think the generated toString-Method
> should recognize it was already called once and return a dummy value or
> just the object reference.
>
>
> Anyway, I got bigger issues using AutoClone:
>
> 1. I use an abstract class to add auditing columns to all my tables. All
> my Entities inherit from that class (AbstractEvent in this example). Since
> these fields should be empty/null on cloning, I'd like to omit the
> AutoClone annotation on that class. But this leads to an error: No
> signature of method: Event.cloneOrCopyMembers() is applicable for argument
> types: (Event) values: [Event(null, null, [], Event@54d9d12d)].
>
> 2. SubEvent objects within Event.subEvents were not cloned.
>
> import groovy.transform.AutoClone
> import groovy.transform.Canonical
> import groovy.transform.ToString
> import static groovy.transform.AutoCloneStyle.SIMPLE
>
> @AutoClone(style=SIMPLE) //1. error when you remove this
> abstract class AbstractEvent {
>
> Date created
> String createdBy
>
> Date modified
> String modifiedBy
> }
>
> @AutoClone(style=SIMPLE)
> @ToString(includeSuper = true)
> class Event extends AbstractEvent {
> Long id
> String someText
>
> ArrayList subEvents = new ArrayList();
> }
>
> @AutoClone(style=SIMPLE)
> @ToString(includeSuper = true, excludes = ['event'])
> class SubEvent extends 

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

2019-02-04 Thread Paul King
+1 to archiving it. I am happy for you to add my name as a maintainer if
that helps.

On Sat, Feb 2, 2019 at 5:29 PM Russel Winder  wrote:

> Hi,
>
> Way back in 2006, Gant was an experiment in scheduling Ant tasks and
> attempted
> to be a build system. Hans Dockter experiment a lot with it, but in the end
> Gant was not the way forward and we got Gradle. Excellently done Hans (and
> Adam).
>
> Gant was still used by GINT for a while so was maintained a bit. However
> Gint3
> will now use Gradle.
>
> Thus does Gant come to its end of existence.
>
> It is my intention to delete *everything* unless someone wants to take
> control
> of the Gant group on GitHub to preserve the code for posterity.
>
> --
> 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
>
>


[ANNOUNCE] Apache Groovy 2.5.6 released

2019-02-04 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.6 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 release is a maintenance release of the GROOVY_2_5_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 24 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344751

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: [PROPOSAL]About creating open collective for Groovy programming language in the name of Groovy Community

2019-01-08 Thread Paul King
On Tue, Jan 8, 2019 at 6:35 PM Daniel Sun  wrote:

> Hi Paul,
>
> > (1) Since we don't use the "groovy/groovy-core" repo any longer, I don't
> > think that is the correct one to use but rather "apache/groovy".
>
>  As you said in (2), `According to official Apache policy, the ASF
> doesn't accept "cash for code"`, I am not sure we can create open
> collective
> for "apache/groovy"


I am not sure either but why not find out for sure? If we (with community
hats on) can, that would be ideal. I will try to find out the right person
to ask.

> (BTW, I can not access "apache/groovy" via my github account).
>

I haven't set mine up either but I believe you can use two factor
authentication now that we are using gitbox:
https://gitbox.apache.org/setup/


>  If we can not use "apache/groovy" to create open collective,
> "groovy/groovy-core" may be better, but we have to explain the reason in
> the
> open collective.
>
> > Also, while the Android Groovy Gradle plugin is no doubt a worthy
> > recipient of additional funds, I would be inclined to keep it simple and
> > focus on core Groovy for now.
>  Agreed.
>
> > this would need to be a community-driven effort rather than an official
> > Apache organised activity
>
>  Yep. That's the reason why I sent the email via my personal hotmail.
>
> > The wording could say "Friends of Groovy", or "All Things Groovy" (to
> > mimic the facebook group) or "Gr8 Technologies" rather than "Apache
> Groovy
> > project" or similar.
>
>  "I would be inclined to keep it simple and focus on core Groovy for
> now. ",  I think wording focuses on core Groovy would be better, e.g.
> "Groovy Programming Language"?
>

I think it needs to be clear up front that it's not associated with Apache
and
just "Groovy Programming Language" while not exactly "Apache Groovy project"
I suspect isn't clear enough. That's why I suggested "Friends of Groovy".

>  I suspect, we (as the Apache project) would need to maintain oversight of
> > the collective to make sure of this. As far as I know this is slightly
> > uncharted territory.
>
>  The opencollective site will record all "contribute" and "submit
> expense", which is open to all people, e.g.
> https://opencollective.com/vuejs#budget


True, that might be enough. We'll have to ask. It does raise the other
question though of how expenses will be approved?


> > (4) While sponsorship is below what we'd like and below what it has been
> > at some previous points in Groovy life, it isn't 0. We have several
> > existing sponsors, e.g. OCI. The wording about the collective should take
> > that into consideration.
>
>  Yep. OCI is a great company for Groovy! We always appreciate its
> sponsorship.
>
>   Let's imagine that would be really great if more people involve into
> developing Groovy, more big features(e.g. MOP2, async/await) are completed
> and hard issues(e.g. generics of STC) are fixed every year :-)
>

Totally agree with you, just suggesting the wording used is sensitive to
existing players. I can help craft wording if needed.


> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>


Re: [ANNOUNCE] Groovy 3.0.0-alpha-4 Windows Installer Released

2018-12-30 Thread Paul King
Thanks Keegan!

For anyone interested, you should be able to use snapshot versions of Spock
with Groovy 3.0.0.


On Mon, Dec 31, 2018 at 11:39 AM Keegan Witt  wrote:

> The Windows installer for Groovy 3.0.0-alpha-4 is available from the
> usual place:
> https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-alpha-4-installer.exe
> .
>
> Note this installer doesn't include Spock since there isn't a Spock
> release compatible with Groovy 3.0.
>
> -Keegan
>


[ANNOUNCE] Apache Groovy 3.0.0-alpha-4 released

2018-12-30 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 3.0.0-alpha-4 of
Apache Groovy. We expect this to be the last "alpha" release of Groovy
3.0.0 as we shift our focus to releasing this next version of Groovy.

2018 was an exciting year for Groovy with download numbers going over
100M in 2018 for the first time. We also had 18 releases and over 30
new contributors. Thanks to you all! We expect 2019 to be even more
exciting as we bring to fruition the hard work (including hundreds of
improvements and fixes) that have already gone into 3.0.0.

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 138 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343541

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.


[ANNOUNCE] Apache Groovy 2.5.5 released

2018-12-23 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.5 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 release is a maintenance release of the GROOVY_2_5_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 20 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344435

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: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Paul King
We don't want to publish a fat jar to maven because it will cause problems
that we will continually be asked about but perhaps having an uber jar
within the zip distribution might be something we could look at. I suspect
over time though that even that could be problematic.

On Thu, Dec 20, 2018 at 8:46 AM MG  wrote:

> Hi,
>
> out of curiosity (and because having a fat jar again might be
> conventient at some point in the future in my work environment (also no
> internet access)):
>
> This solution proposed by Keith does not work
> https://github.com/gradle/gradle-groovy-all
> ?
>
> Cheers,
> mg
>
>
>
> Am 19.12.2018 um 23:33 schrieb Paul Moore:
> > On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:
> >> Paul,
> >>
> >> The best solution is to use Maven or Gradle to create an all-in-one
> (fat) jar that you can ship and run with java -jar
> >>
> >> Gradle has a shadow plugin and Maven has a shade plugin to do just that.
> > Thanks. I'd come to the conclusion that Gradle was likely the solution
> > I should be looking at, and I've spent the evening trying to set up a
> > basic Gradle script that does what I want. After a lot of
> > experimentation, I came up with the following, which seems to do what
> > I want:
> >
> > -- start build.gradle --
> >
> > version = "0.1"
> >
> > configurations {
> >  deploy
> > }
> >
> > dependencies {
> >  deploy 'org.codehaus.groovy:groovy-all:2.5.4'
> > }
> >
> > repositories {
> >  jcenter()
> > }
> >
> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
> > dependencies") {
> >  from configurations.deploy.collect { it.absolutePath }
> >  into "dest/lib"
> > }
> >
> > task copy(type: Copy, group: "Custom", description: "Copies sources to
> > the dest directory") {
> >  from "src"
> >  include "*.groovy"
> >  into "dest"
> > }
> >
> > task deploy(type:Zip, group: "Custom", description: "Build a deployment
> zip") {
> >  dependsOn copyDeps
> >  dependsOn copy
> >  from "dest"
> >  setArchiveName "${project.name}-${project.version}.zip"
> > }
> >
> > -- end build.gradle --
> >
> > It doesn't create a fat jar yet, but I can look into setting that up.
> > The various existing plugins seem to be dependent upon the
> > infrastructure set up by the java plugin, which I don't really
> > understand (or need, as far as I can tell) so they may not be of much
> > help. But I'm not sure what I need to do yet to write my own.
> > Something simple like
> >
> > task customFatJar(type: Jar) {
> >  dependsOn copyDeps
> >  baseName = 'all-in-one-jar'
> >  from "dest/lib"
> > }
> >
> > gives me an "all-in-one-jar.jar" that contains the dependency jars
> > directly included, rather than being unpacked. So there's more I need
> > to do here...
> >
> > Paul
> >
>
>


[ANNOUNCE] Apache Groovy 2.4.16 released

2018-12-13 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.4.16 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 release is a maintenance release of the GROOVY_2_4_X branch.
While we recommend moving to the current 2.5.x releases (currently 2.5.4),
for any users who can't upgrade to 2.5 and are using 2.4.x versions,
we strongly recommend that you upgrade to this version.

This release includes 18 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12342996

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.4 released

2018-11-12 Thread Paul King
Blog entry should have the correct version now.

On Tue, Nov 13, 2018 at 12:00 AM Alessio Stalla 
wrote:

> It says 2.5.4 in the title but 2.5.3 in the actual article.
>
> On Mon, 12 Nov 2018 at 13:07, Remko Popma  wrote:
>
>> Blogged: https://blogs.apache.org/groovy/entry/groovy-2-5-4-released
>>
>> Please share on social media.
>>
>> On Monday, November 12, 2018, Paul King  wrote:
>>
>>> Dear community,
>>>
>>> The Apache Groovy team is pleased to announce version 2.5.4 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 release is a maintenance release of the GROOVY_2_5_X branch.
>>> It is strongly encouraged that all users using prior
>>> versions on this branch upgrade to this version.
>>>
>>> This release includes 15 bug fixes/improvements as outlined in the
>>> changelog:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344270
>>>
>>> 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.
>>>
>>


[ANNOUNCE] Apache Groovy 2.5.4 released

2018-11-11 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.4 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 release is a maintenance release of the GROOVY_2_5_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 15 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12344270

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: Calling 'each' on org.eclipse.emf.common.util.TreeIterator

2018-10-16 Thread Paul King
I'd expect that to work the same as if you used a while loop with hasNext()
and next(). If your data structure has further containers and next()
doesn't normally walk through the containers, then I'd expect you to have
more work to do. Is that not what you are seeing?

Cheers, Paul.

On Tue, Oct 16, 2018 at 8:23 PM Felix Dorner  wrote:

> Hi,
>
> I can do:
> def a = [1,2,3].iterator()
> a.each {
>println it
> }
>
> Cool, I can walk EMF EObject trees like this, I thought:
>
> Iterator i = anEObject.eAllContents() // this gives a TreeIterator, a
> subinterface of Iterator
> it.each {
>   println it
> }
>
> But that doesn't work :(. It only prints anEObject, not the whole content
> tree. Anyone can explain why?
>
>
> --
> Linux. The choice of a GNU generation.
>


Re: GMavenPlus 1.6.2 Released

2018-10-14 Thread Paul King
Excellent work!

On Mon, Oct 15, 2018 at 6:29 AM Keegan Witt  wrote:

> GMavenPlus 1.6.2 has been released to Sonatype OSS
>  and should appear
> in Maven Central  shortly.
> Bugs
>
>- Support for Java 10 bytecode (#104
>)
>- Support for Java 11 bytecode (#106
>)
>- Fixed that could error saying no Groovy dependency when it shouldn't
>because no Groovy sources exist (ef3a3d5
>
> 
>).
>
> Enhancements
>
> None
> Potentially breaking changes
>
> None
> Notes
>
> None
>


Re: [ANNOUNCE] Groovy 2.5.3 Windows Installer Released

2018-10-14 Thread Paul King
That was quick! Thanks!

On Mon, Oct 15, 2018 at 6:32 AM Keegan Witt  wrote:

> The Windows installer for Groovy 2.5.3 is available from the usual place:
> https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.3-installer
> .
>


[ANNOUNCE] Apache Groovy 2.5.3 Released

2018-10-14 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.3 of Apache Groovy.
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

This release is a maintenance release of the GROOVY_2_5_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes over 50 bug fixes/improvements as outlined in
the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343876

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: @Immutable backwards compatibility

2018-10-13 Thread Paul King
On Sun, Oct 14, 2018 at 1:41 AM Daniel.Sun  wrote:

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

The problem is that none of our tests in 2.5.x include tests against 2.4.x
compiled code.
This is what impacts Gradle, Grails and Micronaut plugins. They might be
compiled
with 2.4.x and then used with 2.5.x. The checkBinaryCompatibility task
helps somewhat
but we could no doubt also add some cross version integration tests as well.


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


Re: @Immutable backwards compatibility

2018-09-27 Thread Paul King
I'll move this to the dev list.

On Thu, Sep 27, 2018 at 10:26 PM Jochen Theodorou  wrote:

>
>
> Am 27.09.2018 um 01:24 schrieb Paul King:
> > The String check for "groovy.transform.Immutable" would work fine if the
> > 2.4 compiled class was actually loaded with it;s annotations but
> > AnnotationCollector changes any meta-annotation to no longer be an
> > annotation but a class to store the serialized information for the
> > pre-compiled case.
>
> Was that already in 2.4 the case for @Immutable? I thought it was not
> expressed by the annotation collector back then.
>
> And why do we do all those checks for if the type is annotated with
> @Immutable then? We also check for if the annotation starts with
> groovy.transform.Immutable, which would cover ImmutableBase as well,
> which imho stays on the class... wait...it is source only.. oh..
>
> > I think we need to perhaps adjust what we do there
> > slightly to leave the original annotation intact. I'll try to work on
> > that on the plane trip home - perhaps we should delay 2.5.3 a few days
> > to see if we can address this but any alternative suggestions welcome.
>
> leaving the original annotation in tact is what I suggested to you
> before even writing here, because somehow I knew this was the problem,
> without even having looked at it properly ;)
>
> Still I'd like to really understand it, and I am not there yet.
>
> bye Jochen
>


Re: @Immutable backwards compatibility

2018-09-26 Thread Paul King
The String check for "groovy.transform.Immutable" would work fine if the
2.4 compiled class was actually loaded with it;s annotations but
AnnotationCollector changes any meta-annotation to no longer be an
annotation but a class to store the serialized information for the
pre-compiled case. I think we need to perhaps adjust what we do there
slightly to leave the original annotation intact. I'll try to work on that
on the plane trip home - perhaps we should delay 2.5.3 a few days to see if
we can address this but any alternative suggestions welcome.

On Thu, Sep 27, 2018 at 8:14 AM Jochen Theodorou  wrote:

> On 26.09.2018 12:58, Paul King wrote:
> > I shouldn't try to respond to emails while rushing between conference
> > sessions. Refreshed my memory and yes, the current provisions for 2.4
> > compatibility don't really help. I'll see if Jochen has some ideas on
> > how we could improve that.
>
> I guess we have to compare
>
>
> https://github.com/apache/groovy/blob/e16728b91601573ee18475ec5dee5355817f670c/src/main/org/codehaus/groovy/transform/ImmutableASTTransformation.java#L738
>
> and
>
>
> https://github.com/apache/groovy/blob/9914ae4a0b4273a5a4cb8822699a9b2dbb3c3215/src/main/java/org/codehaus/groovy/transform/ImmutableASTTransformation.java#L352
>
> which tells me the knownImmutableClasses part is gone from @Immutable
> and the 2.5.x version has no way of getting this information anymore,
> since this is supposed to be given directly to the method.
>
> Bad, but let's continue
>
> https://github.com/ajoberstar/grgit/issues/237 talks about for example
> the Commit.groovy, that can be found here:
>
> https://github.com/ajoberstar/grgit/blob/master/grgit-core/src/main/groovy/org/ajoberstar/grgit/Commit.groovy
>
> it does have a knownImmutableClasses=[ZonedDateTime], but looking at
>
> https://github.com/apache/groovy/blob/GROOVY_2_5_X/src/main/java/org/apache/groovy/ast/tools/ImmutablePropertyUtils.java#L101
> it is in the list of builtinImmutables.
>
> And the error message is of course not about that, it is about Person:
>
> https://github.com/ajoberstar/grgit/blob/master/grgit-core/src/main/groovy/org/ajoberstar/grgit/Person.groovy
>
> And that is where I am actually stuck in understanding the issue...
>
> > if (field == null || field instanceof Enum ||
> builtinOrMarkedImmutableClass(field.getClass())) {
> > return field;
> > }
>
> this code for the 2.4 check should have returned, because
> builtinOrMarkedImmutableClass checks if the class of the value for the
> field has an annotation named groovy.transform.Immutable, which is the
> case for Person (see
>
> https://github.com/apache/groovy/blob/9914ae4a0b4273a5a4cb8822699a9b2dbb3c3215/src/main/java/org/apache/groovy/ast/tools/ImmutablePropertyUtils.java#L194
> )
>
> It is similar for Branch.groovy...
>
> So what exactly is not working anymore? I am confused (and it is well
> too late here for looking into such an issue). Cedric, Paul, can you
> explain what exactly goes wrong?
>
> bye Jochen
>


Re: @Immutable backwards compatibility

2018-09-26 Thread Paul King
I shouldn't try to respond to emails while rushing between conference
sessions. Refreshed my memory and yes, the current provisions for 2.4
compatibility don't really help. I'll see if Jochen has some ideas on how
we could improve that.

On Wed, Sep 26, 2018 at 12:01 PM Paul King  wrote:

> I'll have to look a little more closely. There is some provision for
> handling backwards compatibility. The string value of the class name of
> Annotations is compared with "groovy.transform.Immutable", which will
> handle some cases but we've removed the annotation attributes like
> knownClasses so that is probably going to impact the ability of those
> annotations to be even read. We don't need those annotation attributes any
> more but I am unsure whether we can add them back in a way that won't
> impact our annotation collector usage. I'll have to research unless someone
> else knows off the top of their head.
>
> Cheers, Paul.
>
>
> On Tue, Sep 25, 2018 at 4:39 PM Cédric Champeau 
> wrote:
>
>> 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: Long String concatenation failed

2018-09-26 Thread Paul King
Yes, done.

On Wed, Sep 26, 2018 at 2:54 PM Jmeter Tea  wrote:

> Paul King: Thank you, I can live with a workaround of adding a line
> continuation slash at the end of the line
> Can you answer the original question in stackoverflow
> <https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables>
> ?
>
> On Tue, Sep 25, 2018 at 10:27 PM, Paul King  wrote:
>
>>
>> Groovy uses the end of line as the statement terminator unless it can
>> safely tell that the next line should follow on. We didn't allow plus or
>> minus on the next line
>> when working out the list of things to safely accept since it would have
>> been a breaking change for anyone using the unaryPlus or unaryMinus
>> operators..
>> I suspect very few people use that operator as an overloadable operator
>> but some folks might use it in their DSLs for instance.
>>
>> We could create a GEP for Groovy 3.0 to change the behavior. We'd need to
>> outline how to allow the unary operator style.
>>
>> Why not use the line continuation slash at the end of the line:
>>
>> String text= "0"+"1" +
>> "2" \
>> +"3"
>>
>> Cheers, Paul.
>>
>>
>> On Tue, Sep 25, 2018 at 11:47 PM Jmeter Tea  wrote:
>>
>>> *mg: *Yes, I saw that it's working, but still,
>>>
>>> groovy should add sugar to java instead of removing support of working
>>> code in java as:
>>> String text= "0"+"1" +
>>> "2"
>>> +"3";
>>>
>>> Which I'm getting error:
>>> javax.script.ScriptException: groovy.lang.MissingMethodException: No
>>> signature of method: java.lang.String.positive() is applicable for argument
>>> types: () values: []
>>> Possible solutions: notify(), tokenize(), size(), size()
>>>
>>> Can I open a bug in groovy for this?
>>>
>>> On Tue, Sep 25, 2018 at 4:04 PM, mg  wrote:
>>>
>>>> You can have new lines, just move the "<<" oi the end of the previous
>>>> line, so Groovy knows there is more coming (Groovy does not need
>>>> end-of-line semicolons btw):
>>>>
>>>> String text ="" <" <<
>>>>
>>>> vars["id2"] << ""
>>>>
>>>>
>>>>  Ursprüngliche Nachricht 
>>>> Von: Jmeter Tea 
>>>> Datum: 25.09.18 14:54 (GMT+01:00)
>>>> An: users@groovy.apache.org
>>>> Betreff: Re: Long String concatenation failed
>>>>
>>>> Thank for your answers, I still have some comments:
>>>> *mg: *I don't want to have a huge line with 20 parameters that can't
>>>> be seen on screen so I need new lines between parameters
>>>> Nelson, Erick: I don't need XML as the article suggest " builder
>>>> classes to create XML "
>>>>
>>>> On Tue, Sep 25, 2018 at 3:39 PM, Nelson, Erick <
>>>> erick.nel...@hdsupply.com> wrote:
>>>>
>>>>> No, I mean markup builder.
>>>>>
>>>>> Mr Haki says it best….
>>>>>
>>>>>
>>>>> http://mrhaki.blogspot.com/2009/10/groovy-goodness-creating-xml-with.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Erick Nelson
>>>>>
>>>>> Senior Developer – IT
>>>>>
>>>>> HD Supply Facilities Maintenance
>>>>>
>>>>> (858) 740-6523
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From: *mg 
>>>>> *Reply-To: *"users@groovy.apache.org" 
>>>>> *Date: *Tuesday, September 25, 2018 at 5:19 AM
>>>>> *To: *"users@groovy.apache.org" 
>>>>> *Subject: *Re: Long String concatenation failed
>>>>>
>>>>>
>>>>>
>>>>> If it is just the CTE that is the problem, you just have ro move the
>>>>> "<<" to the end of the previous line...
>>>>>
>>>>>
>>>>>
>>>>>  Ursprüngliche Nachricht 
>>>>>
>>>>> Von: Jmeter Tea 
>>>>>
>>>>> Datum: 25.09.18 09:56 (GMT+01:00)
>>>>>
>>>>> An: users@groovy.apache.org
>>>>>
>>>>> Betreff: Long String concatenation failed
>>>>>
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> I have to  concatenate a lot of variables in a script and I want to make 
>>>>> it readable, but I failed to separate lines as in java, The following 
>>>>> code doesn't compile due to:
>>>>>
>>>>> Caused by: 
>>>>> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
>>>>> failed:
>>>>>
>>>>> Script1.groovy: 2: unexpected token: << @ line 2, column 1.
>>>>>
>>>>><< vars["id2"] << ""
>>>>>
>>>>>
>>>>>
>>>>> Code:
>>>>>
>>>>> String text ="" <"
>>>>>
>>>>> << vars["id2"] << "";
>>>>>
>>>>>
>>>>>
>>>>> Is there a workaround or a better way concatenation a string in groovy?
>>>>>
>>>>>
>>>>>
>>>>> Related question:
>>>>>
>>>>>
>>>>> https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables
>>>>>
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>
>>>>
>>>
>


Re: @Immutable backwards compatibility

2018-09-25 Thread Paul King
I'll have to look a little more closely. There is some provision for
handling backwards compatibility. The string value of the class name of
Annotations is compared with "groovy.transform.Immutable", which will
handle some cases but we've removed the annotation attributes like
knownClasses so that is probably going to impact the ability of those
annotations to be even read. We don't need those annotation attributes any
more but I am unsure whether we can add them back in a way that won't
impact our annotation collector usage. I'll have to research unless someone
else knows off the top of their head.

Cheers, Paul.


On Tue, Sep 25, 2018 at 4:39 PM Cédric Champeau 
wrote:

> 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: Long String concatenation failed

2018-09-25 Thread Paul King
Groovy uses the end of line as the statement terminator unless it can
safely tell that the next line should follow on. We didn't allow plus or
minus on the next line
when working out the list of things to safely accept since it would have
been a breaking change for anyone using the unaryPlus or unaryMinus
operators..
I suspect very few people use that operator as an overloadable operator but
some folks might use it in their DSLs for instance.

We could create a GEP for Groovy 3.0 to change the behavior. We'd need to
outline how to allow the unary operator style.

Why not use the line continuation slash at the end of the line:

String text= "0"+"1" +
"2" \
+"3"

Cheers, Paul.


On Tue, Sep 25, 2018 at 11:47 PM Jmeter Tea  wrote:

> *mg: *Yes, I saw that it's working, but still,
>
> groovy should add sugar to java instead of removing support of working
> code in java as:
> String text= "0"+"1" +
> "2"
> +"3";
>
> Which I'm getting error:
> javax.script.ScriptException: groovy.lang.MissingMethodException: No
> signature of method: java.lang.String.positive() is applicable for argument
> types: () values: []
> Possible solutions: notify(), tokenize(), size(), size()
>
> Can I open a bug in groovy for this?
>
> On Tue, Sep 25, 2018 at 4:04 PM, mg  wrote:
>
>> You can have new lines, just move the "<<" oi the end of the previous
>> line, so Groovy knows there is more coming (Groovy does not need
>> end-of-line semicolons btw):
>>
>> String text ="" <" <<
>>
>> vars["id2"] << ""
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: Jmeter Tea 
>> Datum: 25.09.18 14:54 (GMT+01:00)
>> An: users@groovy.apache.org
>> Betreff: Re: Long String concatenation failed
>>
>> Thank for your answers, I still have some comments:
>> *mg: *I don't want to have a huge line with 20 parameters that can't be
>> seen on screen so I need new lines between parameters
>> Nelson, Erick: I don't need XML as the article suggest " builder classes
>> to create XML "
>>
>> On Tue, Sep 25, 2018 at 3:39 PM, Nelson, Erick > > wrote:
>>
>>> No, I mean markup builder.
>>>
>>> Mr Haki says it best….
>>>
>>> http://mrhaki.blogspot.com/2009/10/groovy-goodness-creating-xml-with.html
>>>
>>>
>>>
>>>
>>>
>>> Erick Nelson
>>>
>>> Senior Developer – IT
>>>
>>> HD Supply Facilities Maintenance
>>>
>>> (858) 740-6523
>>>
>>>
>>>
>>>
>>>
>>> *From: *mg 
>>> *Reply-To: *"users@groovy.apache.org" 
>>> *Date: *Tuesday, September 25, 2018 at 5:19 AM
>>> *To: *"users@groovy.apache.org" 
>>> *Subject: *Re: Long String concatenation failed
>>>
>>>
>>>
>>> If it is just the CTE that is the problem, you just have ro move the
>>> "<<" to the end of the previous line...
>>>
>>>
>>>
>>>  Ursprüngliche Nachricht 
>>>
>>> Von: Jmeter Tea 
>>>
>>> Datum: 25.09.18 09:56 (GMT+01:00)
>>>
>>> An: users@groovy.apache.org
>>>
>>> Betreff: Long String concatenation failed
>>>
>>>
>>>
>>> Hello,
>>>
>>> I have to  concatenate a lot of variables in a script and I want to make it 
>>> readable, but I failed to separate lines as in java, The following code 
>>> doesn't compile due to:
>>>
>>> Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
>>> startup failed:
>>>
>>> Script1.groovy: 2: unexpected token: << @ line 2, column 1.
>>>
>>><< vars["id2"] << ""
>>>
>>>
>>>
>>> Code:
>>>
>>> String text ="" <"
>>>
>>> << vars["id2"] << "";
>>>
>>>
>>>
>>> Is there a workaround or a better way concatenation a string in groovy?
>>>
>>>
>>>
>>> Related question:
>>>
>>>
>>> https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables
>>>
>>>
>>>
>>> Thank you
>>>
>>
>>
>


Re: @CompileStatic void method returns null ?

2018-09-03 Thread Paul King
Calling void methods is fine. Expecting a result is the point in question.

For dynamic Groovy, you can't always tell which case you have:

class Foo {
  def bar() { 42 }
  void baz() { }
}

def method(boolean condition, delegate, meth1, meth2) {
  if (condition) delegate."$meth1"()
  else delegate."$meth2"()
}

println method(true, new Foo(), 'bar', 'baz') // 42
println method(false, new Foo(), 'bar', 'baz') // null

Here, "method" is expecting to return some value that happens to be the
last expression, i.e. the result of the if/then/else expression, so we
return null in such cases.

Cheers, Paul.


On Tue, Sep 4, 2018 at 7:38 AM MG  wrote:

> What I meant was: What sense does letting void methods be called make
> for the dynamic case, i.e. the dynamic compiler ? From a programmer's
> perspective, i.e. what is a programming use case for that
> feature/behavior, in dynamic Groovy ?
>
> Of course I can do the following in dynamic Groovy:
>
> // Groovy 2.5.0
> class Goo {
>  //void nogoo() { return 123 } // Dynamic Groovy compiler:
> RuntimeParserException: Cannot use return statement with an expression on a
> method that returns void
>  void nogoo() { 123 }
> }
>
> final goo = new Goo()
>
> println "original: goo.nogoo()=${goo.nogoo()}"
>
> goo.metaClass.nogoo = { return 456 }
>
> println "mopped: goo.nogoo()=${goo.nogoo()}"
>
>
> Which will build, run, and output
>
> original: goo.nogoo()=null
> mopped: goo.nogoo()=456
>
>   i.e. returning 456 from a void method in the second case.
> But if I am using a library that includes the Goo class, why would I
> ever expect a return value from the nogoo method (and therefore call
> it), considering its return type is void ? And if I control the Goo
> class myself, why would I not just change its return type to int or def ?
>
> Cheers,
> mg
>
>
> On 03.09.2018 22:36, Jochen Theodorou wrote:
> > On 03.09.2018 17:13, mg wrote:
> >> But in what scenario does the dynamic behavior make sense ?
> >
> > for a static compiler? none other than being compatible
> >
> > bye Jochen
> >
>
>


Re: @MapConstructor + @CompileStatic on Static Inner Class => CTE

2018-09-03 Thread Paul King
Please create an issue. VerifyError is always a bug.

On Tue, Sep 4, 2018 at 4:55 AM MG  wrote:

> The following code using @MapConstructor on a static inner class raises
> a compile time error (see end of mail; different error when making the
> inner class non-static):
>
> import groovy.transform.CompileStatic
> import groovy.transform.MapConstructor
>
> @CompileStatic
> class GroovyMapConstructorCheck {
>
>  @MapConstructor(noArg = true)
>  static class Goo {
>  final String s0 = "text0"
>  final int x0
>  final String s1
>  final String s2 = "TEXT2"
>  final o0
>
>  @Override
>  public String toString() {
>  return "Goo(|$s0|,|$x0|,|$s1|,|$s2|,|$o0|)"
>  }
>  }
>
>  void go() {
>  println new Goo()
>  println new Goo(s0:"abc")
>  println new Goo(x0:123, s0:"abc")
>  println new Goo(s1:"S1", s2:"S2", x0:-999, o0:new Object(),
> s0:"S0")
>  final goo = new Goo(s1:"S1", s2:"S2", x0:-999, o0:new Object(),
> s0:"S0")
>  }
> }
>
> final check = new GroovyMapConstructorCheck()
> check.go()
>
> /*
> Compile time error:
>
> java.lang.VerifyError: Bad type on operand stack
> Exception Details:
>Location:
>  GroovyMapConstructorCheck$Goo.(Ljava/util/Map;)V @85:
> invokevirtual
>Reason:
>  Type 'GroovyMapConstructorCheck$Goo' (current frame, stack[0]) is
> not assignable to 'groovy/lang/Closure'
>Current Frame:
>  bci: @85
>  flags: { }
>  locals: { 'GroovyMapConstructorCheck$Goo', 'java/lang/Object',
> 'java/lang/String', 'java/lang/String', 'groovy/lang/MetaClass' }
>  stack: { 'GroovyMapConstructorCheck$Goo' }
>Bytecode:
>  0x000: 2ab7 001b 121d 4d2c 2a5f b500 1f2c 5712
>  0x010: 214e 2d2a 5fb5 0023 2d57 2ab6 0027 3a04
>  0x020: 1904 2a5f b500 2919 0457 2bc7 0007 04a7
>  0x030: 0004 0399 001a 03bd 0004 b800 2f3a 0519
>  0x040: 0512 31b8 0035 c000 314c 1905 572a 2bb8
>  0x050: 003b 0157 2ab6 0041 c000 4312 44b9 004a
>  0x060: 0200 9900 232a b600 41c0 0043 1244 b900
>  0x070: 4e02 003a 0619 06b8 0054 c000 562a 5fb5
>  0x080: 001f 1906 572a b600 41c0 0043 1257 b900
>  0x090: 4a02 0099 0020 2ab6 0041 c000 4312 57b9
>  0x0a0: 004e 0200 3a07 1907 b800 5d2a 5fb5 005f
>  0x0b0: 1907 572a b600 41c0 0043 1260 b900 4a02
>  0x0c0: 0099 0023 2ab6 0041 c000 4312 60b9 004e
>  0x0d0: 0200 3a08 1908 b800 54c0 0056 2a5f b500
>  0x0e0: 6219 0857 2ab6 0041 c000 4312 63b9 004a
>  0x0f0: 0200 9900 232a b600 41c0 0043 1263 b900
>  0x100: 4e02 003a 0919 09b8 0054 c000 562a 5fb5
>  0x110: 0023 1909 572a b600 41c0 0043 1264 b900
>  0x120: 4a02 0099 001d 2ab6 0041 c000 4312 64b9
>  0x130: 004e 0200 3a0a 190a 2a5f b500 6619 0a57
>  0x140: b1
>Stackmap Table:
>
> full_frame(@50,{Object[#2],Object[#70],Object[#86],Object[#86],Object[#108]},{})
>  same_locals_1_stack_item_frame(@51,Integer)
>
> full_frame(@77,{Object[#2],Object[#4],Object[#86],Object[#86],Object[#108]},{})
>  same_frame(@133)
>  same_frame(@179)
>  same_frame(@228)
>  same_frame(@277)
>  same_frame(@320)
>
>
>  at
>
> GroovyMapConstructorCheck.go(MapConstructorCheck_inner_class_error.groovy:24)
>
>  at GroovyMapConstructorCheck$go.call(Unknown Source)
>
>  at
>
> MapConstructorCheck_inner_class_error.run(MapConstructorCheck_inner_class_error.groovy:33)
> */
>


Re: Groovy 2.5.* missing in maven central & jcenter

2018-09-01 Thread Paul King
Depending on what you are trying to do, you might get some way with 2.4.x
on JDKs above 8 but 2.5 and 3 alphas have improvements and fixes in some
areas. You might still get certain currently benign warnings even with
those versions.

Re packaging, please read the info in the release notes about repackaging
due to JDK9+ modules:
http://groovy-lang.org/releasenotes/groovy-2.5.html

TL;DR: There is no longer a "fat" all jar just a "fat" all pom.

Cheers, Paul.


On Sat, Sep 1, 2018 at 6:51 PM Tommy Svensson  wrote:

> Hello Groovy fans,
>
> I’m using Groovy and want it to work on later JDKs than 1.8. Apparently
> that requires version 2.5 and up. The problem I’m finding is that this
> version is not downloadable by maven. It is not in maven central nor
> bintrays jcenter. Some files are actually downloaded: javadoc, groovydoc
> and sources! But no binary jars. It can clearly be seen here:
> http://jcenter.bintray.com/org/codehaus/groovy/groovy-all/2.5.2/
>
> The same goes for 2.5.0 and 2.5.1.
>
> Why is that ?
>
> /Tommy
>
>
>
> --
>
>


Re: @CompileStatic void method returns null ?

2018-08-29 Thread Paul King
See also: https://issues.apache.org/jira/browse/GROOVY-8770

Which I presume was also to mimick dynamic behavior.

Cheers, Paul.


On Wed, Aug 29, 2018 at 4:42 AM Jochen Theodorou  wrote:

> On 28.08.2018 19:45, mg wrote:
> > Since I just stumbled across this behavior while helping a junior
> > developer debug his code: Why does statically compiled Groovy (2.5.2)
> > return null from void methods, instead of raising a compile error ?
>
> i was actually not aware we kept this logic for static compilation, but
> essentially it is like that because of dynamic Groovy, which derives
> this from the reflective and methodhandles based method invocation
>
> bye Jochen
>


Re: [ANNOUNCE] Groovy 2.5.2 Windows Installer Released

2018-08-18 Thread Paul King
Thanks Keegan. I added it to the download page.

On Sat, Aug 18, 2018 at 3:14 PM Keegan Witt  wrote:

> The Windows installer for Groovy 2.5.2 is available from the usual place:
> https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.2-installer.exe
> .
>


[ANNOUNCE] Apache Groovy 2.5.2 Relased

2018-08-14 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.2 of Apache Groovy.
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

This release is a maintenance release of the GROOVY_2_5_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 20 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343651
Of particular note are numerous small fixes for trait edge cases and
some important changes for running the Groovy tools on JDK10
(particularly on macOS). Let us know if you spot any further problems.

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: multi-declaration does not work in the for loop, groovy 2.4

2018-08-06 Thread Paul King
Yes, that is by design for 2.4.x, you'll have to bring one of the
declarations outside the loop or use one of the many internal iteration
approaches. The Parrot parser handles that syntax.

On Mon, Aug 6, 2018 at 11:37 PM ocs@ocs  wrote:

> Hi there,
>
> I have just bumped into a — presumably — parser error, which causes that a
> declaration of more variables is not accepted in a for loop:
>
> ===
> 44 */tmp>* /usr/local/groovy-2.4.15/bin/groovy q
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> /private/tmp/q.groovy: 1: unexpected token: = @ line 1, column 13.
>for (int foo=0,bar=0;foo^
> 1 error
> 44 */tmp>* /usr/local/groovy-2.4.15/bin/groovy -version
> Groovy Version: 2.4.15 JVM: 10.0.1 Vendor: "Oracle Corporation" OS: Mac OS
> X
> 45 */tmp>*
> ===
>
> At the moment alas I can't test in newer groovys, not sure whether the
> problem is fixed there or not.
>
> All the best,
> OC
>
>


Re: Groovy with OpenJDK 10 and IntelliJ Build - Solved

2018-07-30 Thread Paul King
The CORBA dependency is nothing to do with Groovy as you point out.

A minor clarification about JAXB. Other Groovy 2.5.0 users on JDK9+ might
also need the JAXB dependency (or a --add-modules switch) but from Groovy
2.5.1 that module is optional and only users of the groovy-jaxb extensions
should be affected. The --add-modules switch won't help from JDK11, so I'd
recommend (only for groovy-jaxb users) to add the JAXB dependency you
mention on their compile classpath and 3 related JAXB jars on their runtime
classpath. See the release notes for more details or have a look at the
build.gradle file for groovy-jaxb if you are using gradle and need a build
that works on 8 and above.

Cheers, Paul.


On Mon, Jul 30, 2018 at 9:17 PM mg  wrote:

> Hi,
>
> we recently had a little bit of time to revisit the OpenJDK 10 build
> problem: As it turns out, it has nothing to do with Groovy, module support,
> or OpenJDK - instead the missing JARs have simply been removed from JDK 10
> (they had only been deprecated in JDK 9 - quick removal after deprecation
> in the Java world will need some getting used to ;-) ).
>
> All one needs to do to remedy the situation is add external dependencies
> replacing the removed JDK functionality to ones project, in our case:
>
> OJDK 10: glassfish-corba-omgapi-3.2.0-b005.jar (for Notes 9)
>
> OJDK 11: jaxb-api-2.3.0.jar (for Vaadin 7)
>
> (All these removals come from the same JEP:
>
> JDK Extension Proposal (no longer a proposal, alreday happening in JDK
> 9/10/11 - e.g. JAXB is gone in 11) betreffend das java.corba Problem, das
> wir gerade gelöst haben:
>
> http://openjdk.java.net/jeps/320  )
>
> Chhers,
> mg
>
>
> On Wed, Jul 4, 2018 at 9:28 AM MG  wrote:
>
>> Hi,
>>
>> does anyone allready have experience compiling a Groovy project under
>> IntelliJ and OpenJDK 10 ?
>> We are currently using OpenJDK 8 and would need to evaluate (if
>> possible) if our Groovy framework has any problems building & running
>> under OpenJDK 10. We are using IntelliJ modules as our build system, and
>> with OpenJDK 10 the Groovy build throws an internal compiler error that
>> NotesException requires a base class from the java.corba module, which
>> can no longer be found. Is there a (quick) way to make Groovy code
>> module compatible under IntelliJ 2018.1.5 ?
>>
>> Cheers,
>> mg
>
>


Re: Groovy and JDK 11: Compilation issue

2018-07-30 Thread Paul King
When I said "fully support JDK11 in Groovy 3 alphas", I should have said
"up to the point that the experimental parts of ASM cover". Having said
that, if you find errors in the JDK11 support, please file a Jira with a
small reproducible test case if possible. It could involve an edge case
that we haven't seen yet or it might be something we need to pass on to the
ASM project.

Cheers, Paul.

On Tue, Jul 31, 2018 at 5:18 AM Paul King  wrote:

> We use ASM 6.2 with the ASM API version set to ASM6 in Groovy 2.5.1.
> We use ASM 6.2 with the ASM API version set to ASM7_EXPERIMENTAL in Groovy
> 3 alphas.
>
> As per ASMs current strategy (archive protected by a spambot link - click
> through and follow date):
>
> https://mail.ow2.org/wws/arc/asm/2018-05/msg0.html
>
> This means that we currently fully support JDK10 in 2.5.x and JDK11 in 3.x
> (bar some warnings and full support for modules which we are working on).
>
> We slide those ASM versions along as new versions are released (after
> testing of course). We have been conservative so far and not tried to put
> the "EXPERIMENTAL" variants in final versions of Groovy. We can re-assess
> that approach if we need to but it might introduce incompatibilities
> between Groovy versions that we'd like to avoid.
>
> Having said that, if you have simple code, you might find that it compiles
> and runs fine on JDK11.
> Or compiles on earlier versions but runs fine on JDK11 and 12 after that.
>
> The master branch of Groovy builds and the runs 10,000+ tests on JDK11
> last I checked.
>
> Cheers, Paul.
>
>
> On Tue, Jul 31, 2018 at 3:33 AM Misagh Moayyed 
> wrote:
>
>> Has anyone here tried to use Apache Groovy 2.5.1 or 3.x and JDK 11
>> together? I am trying to troubleshoot a build failure (Using Gradle 4.8, or
>> 4.9) that manifests itself as:
>>
>> ...
>> General error during class generation:
>> java.lang.UnsupportedOperationException
>> java.lang.UnsupportedOperationException
>> at
>> groovyjarjarasm.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
>> at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:651)
>> at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:391)
>> 
>>
>> Here is the full output of the failure:
>> https://travis-ci.org/apereo/cas/builds/409569422
>>
>> It appears to me that perhaps JDK 11 support for Groovy still has a few
>> rough edges and may not be "officially" there. Could someone confirm this
>> please?
>>
>> Thanks.
>>
>> --Misagh
>>
>


Re: Groovy and JDK 11: Compilation issue

2018-07-30 Thread Paul King
We use ASM 6.2 with the ASM API version set to ASM6 in Groovy 2.5.1.
We use ASM 6.2 with the ASM API version set to ASM7_EXPERIMENTAL in Groovy
3 alphas.

As per ASMs current strategy (archive protected by a spambot link - click
through and follow date):

https://mail.ow2.org/wws/arc/asm/2018-05/msg0.html

This means that we currently fully support JDK10 in 2.5.x and JDK11 in 3.x
(bar some warnings and full support for modules which we are working on).

We slide those ASM versions along as new versions are released (after
testing of course). We have been conservative so far and not tried to put
the "EXPERIMENTAL" variants in final versions of Groovy. We can re-assess
that approach if we need to but it might introduce incompatibilities
between Groovy versions that we'd like to avoid.

Having said that, if you have simple code, you might find that it compiles
and runs fine on JDK11.
Or compiles on earlier versions but runs fine on JDK11 and 12 after that.

The master branch of Groovy builds and the runs 10,000+ tests on JDK11 last
I checked.

Cheers, Paul.


On Tue, Jul 31, 2018 at 3:33 AM Misagh Moayyed  wrote:

> Has anyone here tried to use Apache Groovy 2.5.1 or 3.x and JDK 11
> together? I am trying to troubleshoot a build failure (Using Gradle 4.8, or
> 4.9) that manifests itself as:
>
> ...
> General error during class generation:
> java.lang.UnsupportedOperationException
> java.lang.UnsupportedOperationException
> at
> groovyjarjarasm.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
> at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:651)
> at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:391)
> 
>
> Here is the full output of the failure:
> https://travis-ci.org/apereo/cas/builds/409569422
>
> It appears to me that perhaps JDK 11 support for Groovy still has a few
> rough edges and may not be "officially" there. Could someone confirm this
> please?
>
> Thanks.
>
> --Misagh
>


Re: Groovy 2.5.1 array issue

2018-07-26 Thread Paul King
We took the opportunity with 2.5 to fix a long-known difference in behavior
between Java and Groovy. It is listed in the release notes as a breaking
change.
(Basically if you always stick with just the stack methods (push/pop) or
just the list methods (most other operations) you will be okay but if you
mix and match you need to change.

On Fri, Jul 27, 2018 at 12:39 AM Paolo Di Tommaso 
wrote:

> Dear all,
>
> I've found a evil change in the 2.5.1 when using an array list.
>
>
> The following snippet is OK on 2.4.x
>
> def stack = new ArrayList()
> stack.push('a')
> stack.push('b')
> stack.push('c')
> assert stack.join('.') == 'a.b.c'
>
>
> When using 2.5.1 it the assertion fails
>
>
> stack.join('.') == 'a.b.c'
> | | |
> | c.b.a false
> [c, b, a]   2 differences (60% similarity)
> (c).b.(a)
> (a).b.(c)
>
>
> It looks the semantic of `push` is changed. Is that expected?
>
>
> p
>


[ANNOUNCE] Apache Groovy 2.5.1 released

2018-07-13 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.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.

For this release we focused on fixing up some of the usability/packaging issues
that the 2.5.0 release introduced as part of supporting Groovy across
JDKs 7 through (soon) 11. Maven/Gradle users not needing JAXB should
now have a much improved experience building with the new version.
(SUREFIRE users should read the release notes about some caveats).
In 2.5.2, we should have additional changes to improve the build
experience even further
for JAXB users and users of the Groovy command-line tools. Please read
the release
notes for further information:
http://groovy-lang.org/releasenotes/groovy-2.5.html#Groovy2.5releasenotes-Addendum251

This release is a maintenance release of the GROOVY_2_5_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 44 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343365

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: [ANN] Announcing CodeNarc 1.2

2018-07-09 Thread Paul King
Fantastic to see a new release! Thanks.


On Tue, Jul 10, 2018 at 4:46 AM  wrote:

> The *CodeNarc** Team *is proud to announce the release of version *1.**2*.
>
> *CodeNarc*  is a static analysis tool for Groovy
> source code.
>
> Version *1.**2* includes 5 new rules and several enhancements and bug
> fixes. See the full details in the *release notes*
> .
>
> *New Rules*
>
>- *StaticFieldsBeforeInstanceFields* rule (convention) - Enforce that
>all static fields are above all instance fields within a class.
>- *StaticMethodsBeforeInstanceMethods* rule (convention) - Enforce
>that all static methods within each visibility level (public, protected,
>private) are above all instance methods within that same visibility level.
>- *PublicMethodsBeforeNonPublicMethods* rule (convention) - Enforce
>that all public methods are above protected and private methods.
>- *GrailsDomainStringPropertyMaxSize* rule (grails) - String
>properties in Grails domain classes have to define maximum size otherwise
>the property is mapped to VARCHAR(255) causing runtime exceptions to occur.
>- *NoJavaUtilDate* rule (convention) - Do not use java.util.Date.
>Prefer the classes in the java.time.* packages. Checks for construction of
>new java.util.Date objects.
>
> Check us out on *GitHub* !
>
> The *Grails **CodeNarc** Plugin*  has
> been updated to version *1.**2* as well.
>
>
>
>


Re: [ANNOUNCE] Groovy 3.0.0-alpha-3 Windows Installer Released

2018-07-09 Thread Paul King
Nice work! Thanks!


On Mon, Jul 9, 2018 at 3:41 AM Keegan Witt  wrote:

> The Windows installer for Groovy 3.0.0-alpha-3 is available from the usual
> place:
> https://bintray.com/groovy/Distributions/Windows-Installer/groovy-3.0.0-alpha-3-installer
> .
>


Re: About the groovy code style

2018-07-04 Thread Paul King
Comment inline.

On Tue, Jul 3, 2018 at 10:31 PM Jochen Theodorou  wrote:

>
>
> Am 03.07.2018 um 04:44 schrieb Daniel.Sun:
> > Hi all,
> >
> >   The following code is supported in the older parser, but I propose
> to
> > stop supporting the ugly code style in the new Parrot parser. Any
> thoughts?
> >
> > 1) import statement ( https://issues.apache.org/jira/browse/GROOVY-8642
> )
> > ```
> > import java.
> > lang.
> > Object
> > ```
> >
> > 2) prefix operator ( https://issues.apache.org/jira/browse/GROOVY-8650 )
> > ```
> > def c = --
> > 1
>
> I do not need these.. but since I know Danil is doing special things
> with DSL, maybe we should first ask him if he needs that and why
>

Jochen, even though you say you "do not need these", the real question is
what set of rules are you replacing the existing conceptual rule with?

Existing rule: if the set of tokens parsed when an end of line is reached
doesn't make a complete expression/statement, continue reading tokens as if
the EOL wasn't there.

There are exceptions, e.g. we currently don't allow single quote and single
double quoted strings to span multiple lines but the list is short.

What are your new rules and new list of exceptions?

We shouldn't be tied down by our existing set of rules but we want to keep
them simple for our users so they all don't need to be grammar experts to
use the language.

Cheers, Paul.


> bye Jochen
>


Re: Groovy with OpenJDK 10 and IntelliJ Build

2018-07-03 Thread Paul King
Does the JDK you run Intellij under need to be the same as what your
project settings point to?

On Wed, Jul 4, 2018 at 9:28 AM MG  wrote:

> Hi,
>
> does anyone allready have experience compiling a Groovy project under
> IntelliJ and OpenJDK 10 ?
> We are currently using OpenJDK 8 and would need to evaluate (if
> possible) if our Groovy framework has any problems building & running
> under OpenJDK 10. We are using IntelliJ modules as our build system, and
> with OpenJDK 10 the Groovy build throws an internal compiler error that
> NotesException requires a base class from the java.corba module, which
> can no longer be found. Is there a (quick) way to make Groovy code
> module compatible under IntelliJ 2018.1.5 ?
>
> Cheers,
> mg
>
>
>
>


Groovy 2.5.1 planning

2018-07-03 Thread Paul King
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: About the groovy code style

2018-07-02 Thread Paul King
I think it is worth reviewing some of these edge cases but we want to keep
the overall conceptual
model describing the parser behavior (i.e. parser rules) as simple as
possible.

Here is my understanding of the rules for the classic parser. Java supports
a fluent api style such as:

String lowerCity = person
.getAddress()
.getCity()
.getName()
.toLowerCase();

Java knows when to stop because of the trailing semicolon. Groovy doesn't
require the trailing
semicolon so has the following additional rules. If the tokens at the end
of a line don't make up
a complete expression, looking onto the next line is done. This accounts
for various opening and
closing delimiters but also when using '.'. This allows expressions like:

assert person.
address.
city.
name.
toLowerCase() == 'berlin'

and:

def foobar1 = 'foo' +
'bar1'
assert foobar1.size() == 7

def baz =
 'baz'
println baz

As a follow-on rule, even if a line ends with valid tokens but the
subsequent line doesn't start with
valid tokens (in particular starts with a '.') we try to join. This allows
for:

assert person
.address
.city
.name
.size() == 6

But doesn't allow for:

def foobar2 = 'foo'
+ 'bar2'

which compiles but gives a runtime error:
MissingMethodException: No signature of method: java.lang.String.positive()

Since + here is the unary plus operator which while seldom used in that
fashion is a valid operator.

Strangely, the foobar2 example parses and runs successfully on Groovy 3
setting
foobar2 to 'foo'. I'll have to check if that is a bug or "feature".

Groovy 2.5 similarly doesn't allow:

println 'foo'.with
{ s -> s.size() }

It compiles but fails to find the 'with' property on the 'foo' String. So
these are two
fully valid expressions one after the other.

Groovy 3 does allow this last case. That's a breaking change. I'll need to
double
check if that is something we have discussed previously and add it to the
3.0 breaking
changes if so.

Neither Groovy 2.5 nor 3 supports an anonymous inner class creation with the
curly brace on the subsequent line:

def bar = new Object()
{ String toString() { 'bar' } } // Method def not expected here
println bar.toString()

Anyway, given the above rules, my first inclination would be to retain
at least the GROOVY-8642 syntax and possibly GROOVY-8650.
I agree the use of those rules within an import is ugly but I see it
as consistent application of those rules.

But having said that, if we can describe an alternative set of rules
that are just as simple, we can have a slightly refined way of describing
the parser behavior for Groovy 3.0. I'd prefer not though to have
a very piece-meal set of rules where every construct needs to be
described separately.

Cheers, Paul.

On Tue, Jul 3, 2018 at 12:44 PM Daniel.Sun  wrote:

> Hi all,
>
>  The following code is supported in the older parser, but I propose to
> stop supporting the ugly code style in the new Parrot parser. Any thoughts?
>
> 1) import statement ( https://issues.apache.org/jira/browse/GROOVY-8642 )
> ```
> import java.
> lang.
> Object
> ```
>
> 2) prefix operator ( https://issues.apache.org/jira/browse/GROOVY-8650 )
> ```
> def c = --
> 1
> ```
>
> 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
>


[ANNOUNCE] Apache Groovy 3.0.0-alpha-3 released

2018-06-26 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 3.0.0-alpha-3 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 41 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343061

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.


[ANNOUNCE] Apache Groovy 2.6.0-alpha-4 released

2018-06-26 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.6.0-alpha-4 of
Apache Groovy. This is the last planned release in the 2.6 stream of
releases.

The Groovy 2.6 stream of releases was created as a cut-down version of
Groovy 3.0 back-ported to JDK7 but with features requiring JDK8
removed or offered with reduced functionality. We have decided to
retire this stream as of this release (2.6.0-alpha-4) to focus on
delivering Groovy 3.0 in a more timely fashion. Users wanting a
version supporting the Parrot parser but who are stuck on JDK7 should
use this version. Users on JDK8 and above should move straight to
Groovy 3.0 when available.

Apache Groovy is a multi-facet 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 65 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12342855

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: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

2018-06-22 Thread Paul King
There was overwhelming support to drop 2.6 to focus on 3.0 and mixed
feedback
on whether to do one more 2.6 alpha release or not. So, I'll go ahead and
do one more
2.6 alpha release - quite possibly much less work than further discussions
and it gives
us a clean end point which I am highly in favour of to reduce subsequent
discussions
about what exactly was in the last alpha release.

We aren't planning to delete the branch - so it's still around if we need
some
further emergency regression fixes down the track, but we aren't planning
to do
any merges, so it will start to go out of sync with other branches. So even
if you
have an "emergency fix" for that branch, we'd encourage you to have a
discussion
on the mailing list before creating PRs against that branch.

Cheers, Paul.


On Sat, Jun 16, 2018 at 8:55 AM Robert Stagner  wrote:

> option #2 for me
>
> On Wed, Jun 13, 2018 at 12:06 AM Paul King  wrote:
>
>>
>> Hi everyone,
>>
>> There was some discussion at gr8conf about how to speed up delivery of
>> Groovy 3.0. Some of that discussion was around the scope of what we want to
>> include and have yet to complete in 3.0 but I won't discuss that right now.
>>
>> One of the other discussion points was Groovy around 2.6. As many of you
>> know, we have released alpha versions of Groovy 2.6. That version is a
>> backport of most but not all of Groovy 3.0 to JDK7 including the Parrot
>> parser (though it isn't enabled by default). The purpose of this version
>> has always been to assist people/projects wanting to use the Parrot parser
>> but who might be stuck on JDK7. So in some sense it is an intermediate
>> version to assist with porting towards Groovy 3.0. While that is still a
>> noble goal in theory, in practice, many of our users are already on JDK8
>> and we have limited resources to work on many potential areas.
>>
>> With that in mind, we'd like to understand the preferences in our user
>> base for the following two options:
>>
>> Option 1: please continue releasing the best possible 2.6 even if that
>> slows down the final release of Groovy 3.0 and delays further work on
>> better support for JDK9+.
>>
>> Option 2: please release one more alpha of 2.6 over the next month or so
>> which will become the best version to use to assist porting for users stuck
>> on JDK7 and then focus on 3.0. The 2.6 branch will essentially be retired
>> though we will consider PRs from the community for critical fixes.
>>
>> Feedback welcome.
>>
>> Cheers, Paul.
>>
>>
>>


Re: GraalVM/Truffle ?

2018-06-14 Thread Paul King
As it turns out, I haven't tried the indy artifacts/compilation switches as
yet, just the "classic/standard" jars. I'd suspect though that most benefit
would occur if targeting the GraalVM specifically when generating bytecode.

Cheers, Paul.

On Thu, Jun 14, 2018 at 10:42 PM Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> It’s interesting that it is slower, because I thought the point of it was
> to improve performance, especially regarding escape analysis and
> invokedynamic instruction? They’ve been publishing some very interesting
> benchmarks. The AOT mode is very interesting, too, especially if someone
> wanted to make some CLI commands in Groovy, although the resulting
> executables are still very large if you just wanted to make some shell
> “scripts” in Groovy. Though, I would suspect its AOT mode is not very
> compatible with Groovy due to extensive use of reflection.
>
>
>
> Jason
>
>
>
> *From:* Paul King [mailto:pa...@asert.com.au]
> *Sent:* Thursday, June 14, 2018 4:30 AM
> *To:* users@groovy.apache.org
> *Subject:* Re: GraalVM/Truffle ?
>
>
>
> Running numerous scripts on GraalVM worked fine for me and was only
> slightly slower in my tests than the standard Oracle JVM. I haven't done
> extensive testing though.
>
>
>
> As for actually leveraging any special GraalVM capabilities, I am not
> aware of any completed work/concrete plans to date.
>
>
>
> As for licensing, it may or may not be an issue. We'll have to see how
> things progress before we can say.
>
>
>
> Cheers, Paul.
>
>
>
>
>
> On Thu, Jun 14, 2018 at 1:33 AM MG  wrote:
>
> Since GraalVM (https://en.wikipedia.org/wiki/GraalVM
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGraalVM=02%7C01%7CJason.Winnebeck%40windstream.com%7Ce67a260963094d72ed7008d5d1d10f35%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C636645618198046382=oRUQ9fKzVaQXVOfwFCvleWQIbsWWWh1uIoSuaJCOfaI%3D=0>)
> was mentioned here
> recently: Do we have any statement on plans of Groovy with regards to
> GraalVM, including Truffle ? It might be good to have an official
> statement here on the main Groovy page and on Wikipedia
> (https://en.wikipedia.org/wiki/Apache_Groovy
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FApache_Groovy=02%7C01%7CJason.Winnebeck%40windstream.com%7Ce67a260963094d72ed7008d5d1d10f35%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C636645618198056394=THXlJXbqPZTA5td46Ore5UcoH9eTVnDkChajzmUCego%3D=0>),
> even if it e.g., in
> essence, just states "Groovy runs/will run fine on GraalVM", "The
> Truffle license (GPL 2.0 w CP exception) is not compatible with Apache
> Groovy" or "Truffle makes no sense for Groovy (at this point)"...
>
> Cheers,
> mg
>
> 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: GraalVM/Truffle ?

2018-06-14 Thread Paul King
Running numerous scripts on GraalVM worked fine for me and was only
slightly slower in my tests than the standard Oracle JVM. I haven't done
extensive testing though.

As for actually leveraging any special GraalVM capabilities, I am not aware
of any completed work/concrete plans to date.

As for licensing, it may or may not be an issue. We'll have to see how
things progress before we can say.

Cheers, Paul.


On Thu, Jun 14, 2018 at 1:33 AM MG  wrote:

> Since GraalVM (https://en.wikipedia.org/wiki/GraalVM) was mentioned here
> recently: Do we have any statement on plans of Groovy with regards to
> GraalVM, including Truffle ? It might be good to have an official
> statement here on the main Groovy page and on Wikipedia
> (https://en.wikipedia.org/wiki/Apache_Groovy), even if it e.g., in
> essence, just states "Groovy runs/will run fine on GraalVM", "The
> Truffle license (GPL 2.0 w CP exception) is not compatible with Apache
> Groovy" or "Truffle makes no sense for Groovy (at this point)"...
>
> Cheers,
> mg
>
>
>


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

2018-06-13 Thread Paul King
On Wed, Jun 13, 2018 at 5:11 PM, David Dawson <
david.daw...@simplicityitself.com> wrote:

> I would vote 2.
>
> Actually, i would vote 3) abandon 2.6 immediately.
>

We identified a few major things that were broken in the previous alpha
release of
2.6 but only due to trivial packaging issues, hence the plan to do one more
release.

Also, Jesper identified a few things that can easily be aligned from 3.0 in
a very short period of time. I am happy to wait for his thumbs up before
proceeding.

I am also keen on releasing another alpha of 3.0 at the same time as the
2.6 alpha.
I believe that will make our life easier when answering future
support-oriented questions
about 2.6 on the mailing list going forward.

So, doing one more alpha release of 2.6 has minimal impact on 3.0 timing
and leaves
us in as clean a state as can be hoped for when retiring a previously
planned branch.

Cheers, Paul.


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

2018-06-13 Thread Paul King
On Wed, Jun 13, 2018 at 10:11 PM, Corum, Michael  wrote:

> If 3.0 will still support JDK8, I’d vote for option 3 as well.  If 3 will
> require 9, then maybe option 2.
>
>
>
Groovy 3.0 has JDK8 as minimum.

Cheers, Paul.


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

2018-06-13 Thread Paul King
Hi everyone,

There was some discussion at gr8conf about how to speed up delivery of
Groovy 3.0. Some of that discussion was around the scope of what we want to
include and have yet to complete in 3.0 but I won't discuss that right now.

One of the other discussion points was Groovy around 2.6. As many of you
know, we have released alpha versions of Groovy 2.6. That version is a
backport of most but not all of Groovy 3.0 to JDK7 including the Parrot
parser (though it isn't enabled by default). The purpose of this version
has always been to assist people/projects wanting to use the Parrot parser
but who might be stuck on JDK7. So in some sense it is an intermediate
version to assist with porting towards Groovy 3.0. While that is still a
noble goal in theory, in practice, many of our users are already on JDK8
and we have limited resources to work on many potential areas.

With that in mind, we'd like to understand the preferences in our user base
for the following two options:

Option 1: please continue releasing the best possible 2.6 even if that
slows down the final release of Groovy 3.0 and delays further work on
better support for JDK9+.

Option 2: please release one more alpha of 2.6 over the next month or so
which will become the best version to use to assist porting for users stuck
on JDK7 and then focus on 3.0. The 2.6 branch will essentially be retired
though we will consider PRs from the community for critical fixes.

Feedback welcome.

Cheers, Paul.


[ANNOUNCE] Apache Groovy 2.5.0 released

2018-05-30 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.0 of Apache Groovy!
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

We are sure you'll enjoy the features in this new version of Groovy.
Your feedback on any unintentional glitches is welcome.

This release includes 12 bug fixes/improvements since the last RC as
outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343341

The full list of over 300 bug fixes/improvements since 2.4 can be found here:
http://groovy-lang.org/changelogs/changelog-2.5.0.html

The full release notes can be found here:
http://groovy-lang.org/releasenotes/groovy-2.5.html

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: Groovy 2.5.0 IntelliJ support ?

2018-05-29 Thread Paul King
Actually, we still have more work to do in Groovy's compiler for
@NamedParam too.

On Tue, May 29, 2018 at 8:21 PM, Daniel.Sun  wrote:

> Thanks for your nice work!
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>


Re: does 2.5 break CliBuilder?

2018-05-25 Thread Paul King
Do you have a standalone example which triggers the error, i.e. with map
and config already set? That will save us time reproducing.

Cheers, Paul.

On Sat, May 26, 2018 at 2:59 AM, Nelson, Erick 
wrote:

> Caught: groovy.lang.ReadOnlyPropertyException: Cannot set readonly
> property: opt for class: org.apache.commons.cli.Option
>
> groovy.lang.ReadOnlyPropertyException: Cannot set readonly property: opt
> for class: org.apache.commons.cli.Option
>
>at script.Cli.createOption(Cli.groovy:158)
>
>at script.Cli.createDefaultOptions(Cli.groovy:88)
>
>at script.Cli.(Cli.groovy:29)
>
>at test_cli.run(test_cli.groovy:6)
>
>
>
> I see that it upgrades from commons-cli 1.2 to 1.4
>
>
>
> Code snippet…
>
> I’m dynamically trying to build default command line options for my
> scripting framework.
>
> This works in 2.4
>
>
>
> // validate the option
>
> Integer slen = map.opt.*length*() // short opt length
>
> Integer llen = map.longOpt.*length*() // long opt length
>
> if (slen > 1 || llen == 1 || (slen == 0 && llen == 0)) {
>
> log.warn "invalid cli opt definition [$config]"
>
> return
>
> }
>
> if (slen) {
>
> if (builder.options.getOption(map.opt)) {
>
> log.warn "opt already used [$config]"
>
> return
>
> }
>
> }
>
> if (llen) {
>
> if (builder.options.getOption(map.longOpt)) {
>
> log.warn "longOpt already used [$config]"
>
> return
>
> }
>
> }
>
> // add the option
>
> Map builderOption = [:]
>
> if (llen > 0) {
>
> builderOption.longOpt = map.longOpt
>
> }
>
> if (slen > 0) {
>
> builderOption.opt = map.opt
>
> }
>
> if (map.argName) {
>
> builderOption.args = 1
>
> builderOption.argName = map.argName
>
> }
>
> builder."${map.opt ?: '_'}"(builderOption, map.desc)  // problem
> is here
>
>
>
>
>
>
>


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

2018-05-22 Thread Paul King
This is the place to look:

http://groovy-lang.org/releasenotes/groovy-2.5.html

We still need to do some updates between now and GA release.

Cheers, Paul.

On Wed, May 23, 2018 at 2:16 AM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> Is there a page summarizing the changes since 2.4, to evaluate if/where
> any issues are with backwards compatibility?
>
> Jason Winnebeck
>
> -Original Message-
> From: Paul King [mailto:pa...@apache.org]
> Sent: Tuesday, May 22, 2018 12:03 PM
> To: d...@groovy.apache.org; users@groovy.apache.org; annou...@apache.org
> Subject: [ANNOUNCE] Apache Groovy 2.5.0-rc-3 released
>
> Dear community,
>
> The Apache Groovy team is pleased to announce version 2.5.0-rc-3 of Apache
> Groovy.
> 
>
> 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.
>


[ANNOUNCE] Apache Groovy 2.5.0-rc-3 released

2018-05-22 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.0-rc-3 of
Apache Groovy.
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

Pending any last minute feedback we anticipate this being the LAST RC
for this new version of Groovy with a final release due shortly.
We greatly appreciate any feedback you can give us when using this version.

This release includes 27 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343166

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: groovysh problem in Groovy 2.5.0-rc-2

2018-05-08 Thread Paul King
That isn't supposed to happen and should be fixed in rc-3. We are making
some changes that didn't quite get finished for rc-2. Command-line
processing is in a semi-stable state right now and testing of groovysh
slipped through the cracks. The groovysh tests currently run against the
pre jarjar'd version of the class files.

On Wed, May 9, 2018 at 4:59 AM, Bahman Movaqar  wrote:

> I am able to produce the same behaviour on my machine (Linux + OpenJDK
> 1.8.0_162).
>
> If you're just getting acquainted with Groovy, I'd suggest you use 2.4.x
> series which is stable and well tested:  https://dl.bintray.com/groovy/
> maven/apache-groovy-binary-2.4.15.zip
>
> On 8 May 2018 at 20:25, Lucas Buchala  wrote:
>
>> Hello.
>>
>> I have just unpacked Groovy 2.5.0-rc-2 and groovysh doesn't seem to be
>> working:
>>
>> $ groovysh
>> java.lang.reflect.InvocationTargetException
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovySta
>> rter.java:114)
>> at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.
>> java:136)
>> Caused by: org.codehaus.groovy.runtime.typehandling.GroovyCastException:
>> Cannot cast object
>> 'org.codehaus.groovy.tools.shell.util.HelpFormatter@b10754' with class
>> 'org.codehaus.groovy.tools.shell.util.HelpFormatter' to class
>> 'groovyjarjarcommonscli.HelpFormatter'
>> at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransfor
>> mation.continueCastOnSAM(DefaultTypeTransformation.java:414)
>> at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransfor
>> mation.continueCastOnNumber(DefaultTypeTransformation.java:328)
>> at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransfor
>> mation.castToType(DefaultTypeTransformation.java:242)
>> at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:2717)
>> at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:3782)
>> at groovy.lang.MetaClassImpl.setProperties(MetaClassImpl.java:
>> 1759)
>> at org.codehaus.groovy.runtime.callsite.ConstructorSite$NoParam
>> Site.callConstructor(ConstructorSite.java:125)
>> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCa
>> llConstructor(CallSiteArray.java:59)
>> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCo
>> nstructor(AbstractCallSite.java:238)
>> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCo
>> nstructor(AbstractCallSite.java:250)
>> at org.codehaus.groovy.tools.shell.Main.main(Main.groovy:78)
>> ... 6 more
>>
>> Am I doing anything wrong? (I'm not experienced in Groovy/Java)
>> Or... can anyone confirm this problem?
>>
>
>


[ANNOUNCE] Apache Groovy 2.5.0-rc-2 released

2018-05-05 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.5.0-rc-2 of
Apache Groovy.
Apache Groovy is a multi-facet 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 16 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343030

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: [FYI] Hadoop and Spark examples in Groovy

2018-05-03 Thread Paul King
Nice work Daniel!

On Thu, May 3, 2018 at 7:09 PM, Daniel.Sun  wrote:

> Hi all,
>
>Here are Hadoop example[1] and Spark example[2] in Groovy for your
> reference.
>
>As you can see, Groovy can work very well with the big data
> frameworks. Even if Spark is implemented in Scala, the code of Spark
> example
> in Groovy is as concise as Scala's.
>
>The reason why I wrote the examples is to assure you that Groovy is
> powerful and elegant enough to handle any scenario in the Java world :-)
>
> Cheers,
> Daniel.Sun
>
> [1] https://github.com/danielsun1106/hadoop-wordcount
> [2] https://github.com/danielsun1106/spark-wordcount
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>


Re: [Poll] About supporting Java-like array

2018-04-30 Thread Paul King
I suggested CodeNarc first partly because it would be a little bit of work
to add warnings - the Groovy compiler doesn't really have any at present.
Also, Groovy has tried to not be too opinionated. If you leave those
semicolons in, Groovy won't complain. Of course removing the semicolons is
its own reward! :-)

Cheers, Paul.

On Mon, Apr 30, 2018 at 10:30 PM, mg <mg...@arscreat.com> wrote:

> Yes, but what about all the (hopefully many) people new to Groovy, who
> don't use CodeNarc ? How do you educate them about what is idiomatic Groovy
> ?
> Especially in cases like this, where a completely equivalent Groovy
> alternative exists...
>
> I imagine something along the line:
>
> Warning: Using {...} Java style array literals is not idiomatic Groovy. To
> avoid confusion with Groovy closures, it is recommended to use the
> performance-identical Groovy [...] list literal syntax instead.
>
> I think we should decide if that is something we want to do in general, or
> not. My argument for it is, to avoid Groovy becoming a
> Babylonian-syntax-language like e.g. Ruby...
>
> Cheers,
> mg
>
>
>
>
>
>  Ursprüngliche Nachricht 
> Von: Paul King <pa...@asert.com.au>
> Datum: 30.04.18 01:51 (GMT+01:00)
> An: users@groovy.apache.org
> Betreff: Re: [Poll] About supporting Java-like array
>
>
>
> On Mon, Apr 30, 2018 at 9:10 AM, mg <mg...@arscreat.com> wrote:
>
>> I would propose the Groovy compiler issue a warning to change the array
>> initialization from Java- to Groovy-style then...
>>
>
> A codenarc rule would be a great first option.
>
>
>> Cheers,
>> mg
>>
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: Paul King <pa...@asert.com.au>
>> Datum: 30.04.18 00:29 (GMT+01:00)
>> An: users@groovy.apache.org
>> Betreff: Re: [Poll] About supporting Java-like array
>>
>> The preferred Groovy syntax would probably still remain:
>>
>> int[] fibs = [1, 1, 2, 3, 5, 8]
>>
>> Cheers, Paul.
>>
>> On Mon, Apr 30, 2018 at 7:17 AM, MG <mg...@arscreat.com> wrote:
>>
>>> After thinking about this some more for the last weeks
>>> +1 with asterisk
>>> from my side:
>>>
>>> 1) I am always for being as Java compatible as possible (though I see
>>> that this might not be feasible in all cases in the future, due to Java
>>> changing at a much faster pace and with more syntax changes now than
>>> before; example: Java considered naming the new "var" keword "def", which
>>> is similar to but not the same as Java-var in Groovy...)
>>>
>>> 2) I feel  { { } } being interpreted as an array containing an empty
>>> closure is confusing, i.e. not least surprise. I would rather not see it
>>> cut it so close with regards to what the Parrot parser can handle
>>> syntax-wise. What do others think ?
>>>
>>> 3) After introducing this syntax extension, what will be considered the
>>> "Groovy way" of initializing an array in the future ? Is it still
>>> final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]
>>> or
>>> final int[] a = { 1, 1, 2, 3, 5, 8 }
>>> ?
>>> In the 2nd case I would be worried that the core Groovy syntax becomes
>>> all over the place over time, same as with the new Java lambda syntax
>>> (though less pronounced, since using/initializing arrays is typically rare).
>>>
>>> 4) I am not too worried about the breaking edge cases, because I feel
>>> they are quite rare in practice, the compiler catches them, and they are
>>> easy to fix.
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>>
>>>
>>> On 29.04.2018 15:29, Paul King wrote:
>>>
>>> +1
>>>
>>> For completeness, I added some more details about the breaking changes
>>> and workarounds into the issue - included below for easy reading.
>>>
>>> Cheers, Paul.
>>>
>>> =
>>>
>>> Groovy currently "promotes" a singleton instance of an object into an
>>> array for assignments, e.g.:
>>>
>>> Integer[] nums = 42
>>> assert nums instanceof Integer[]
>>> assert nums.size() == 1
>>> assert nums[0] instanceof Integer
>>>
>>> This aligns with how Groovy behaves if you try to call `.each{}` on a
>>> non-aggregate. It treats it like a singleton collection and "iterates" over
>>> the one item.
>>>
>>> The existing behavior also currently works 

Re: [Poll] About supporting Java-like array

2018-04-29 Thread Paul King
That sounds like a limitation we'd like to remove when using
@CompileStatic. Want to create a Jira?

Cheers, Paul.

On Mon, Apr 30, 2018 at 12:39 PM, MG  wrote:

> Hi Daniel,
>
> I did a quick check and it works with dynamic Groovy, but is rejected
> under static compilation:
>
> @Test@Ignorevoid arrayFromListLiteral() {
>   int[] a0 = [1,2,3]
>   int[][] aa0 = [[1,2,3],[4,5,6]]
>   int[][][] aaa0 = [[[1],[2],[3]],[[4],[5],[6]]]
>   int[][][] aaa1 = [[1,2,3],[4,5,6]]
>   int[][][] aaa2 = [1,2,3,4,5,6]
>   int[][][] aaa3 = 1  println "a0=$a0"  println "aa0=$aa0"  println 
> "aaa0=$aaa0"  println "aaa1=$aaa1"  println "aaa2=$aaa2"  println 
> "aaa3=$aaa3"  assert a0 instanceof int[]
>   assert aa0 instanceof int[][]
>   assert aaa0 instanceof int[][][]
>   assert aaa1 instanceof int[][][]
>   assert aaa2 instanceof int[][][]
>   assert aaa3 instanceof int[][][]
> }
>
> gives:
>
> a0=[1, 2, 3]
> aa0=[[1, 2, 3], [4, 5, 6]]
> aaa0=[[[1], [2], [3]], [[4], [5], [6]]]
> aaa1=[[[1], [2], [3]], [[4], [5], [6]]]
> aaa2=[[[1]], [[2]], [[3]], [[4]], [[5]], [[6]]]
> aaa3=[[[1]]]
>
>
> with @CompileStatic the compiler gives:
>
> Error:(37, 19) Groovyc: [Static type checking] - Cannot assign value of
> type java.util.List  into array of type int[][]
> Error:(38, 22) Groovyc: [Static type checking] - Cannot assign value of
> type java.util.List  into array of type int[][][]
> Error:(39, 22) Groovyc: [Static type checking] - Cannot assign value of
> type java.util.List  into array of type int[][][]
> Error:(40, 22) Groovyc: [Static type checking] - Cannot assign value of
> type int into array of type int[][][]
> Error:(41, 22) Groovyc: [Static type checking] - Cannot assign value of
> type int to variable of type int[][][]
>
> and one has to do
>
> int[][] aa0 = [[1,2,3],[4,5,6]] as int[][]
>
> etc
>
> Cheers,
> mg
>
>
>
>
> On 30.04.2018 02:02, Daniel Sun wrote:
>
> Hi mg,
>
>  As far as I remember, two dimensional array like`int[][] a = [[1, 2,
> 3], [4, 5, 6]]` will go wrong in the Groovy style.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>
>
>


Re: [Poll] About supporting Java-like array

2018-04-29 Thread Paul King
On Mon, Apr 30, 2018 at 9:10 AM, mg <mg...@arscreat.com> wrote:

> I would propose the Groovy compiler issue a warning to change the array
> initialization from Java- to Groovy-style then...
>

A codenarc rule would be a great first option.


> Cheers,
> mg
>
>
>
>  Ursprüngliche Nachricht 
> Von: Paul King <pa...@asert.com.au>
> Datum: 30.04.18 00:29 (GMT+01:00)
> An: users@groovy.apache.org
> Betreff: Re: [Poll] About supporting Java-like array
>
> The preferred Groovy syntax would probably still remain:
>
> int[] fibs = [1, 1, 2, 3, 5, 8]
>
> Cheers, Paul.
>
> On Mon, Apr 30, 2018 at 7:17 AM, MG <mg...@arscreat.com> wrote:
>
>> After thinking about this some more for the last weeks
>> +1 with asterisk
>> from my side:
>>
>> 1) I am always for being as Java compatible as possible (though I see
>> that this might not be feasible in all cases in the future, due to Java
>> changing at a much faster pace and with more syntax changes now than
>> before; example: Java considered naming the new "var" keword "def", which
>> is similar to but not the same as Java-var in Groovy...)
>>
>> 2) I feel  { { } } being interpreted as an array containing an empty
>> closure is confusing, i.e. not least surprise. I would rather not see it
>> cut it so close with regards to what the Parrot parser can handle
>> syntax-wise. What do others think ?
>>
>> 3) After introducing this syntax extension, what will be considered the
>> "Groovy way" of initializing an array in the future ? Is it still
>> final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]
>> or
>> final int[] a = { 1, 1, 2, 3, 5, 8 }
>> ?
>> In the 2nd case I would be worried that the core Groovy syntax becomes
>> all over the place over time, same as with the new Java lambda syntax
>> (though less pronounced, since using/initializing arrays is typically rare).
>>
>> 4) I am not too worried about the breaking edge cases, because I feel
>> they are quite rare in practice, the compiler catches them, and they are
>> easy to fix.
>>
>> Cheers,
>> mg
>>
>>
>>
>>
>> On 29.04.2018 15:29, Paul King wrote:
>>
>> +1
>>
>> For completeness, I added some more details about the breaking changes
>> and workarounds into the issue - included below for easy reading.
>>
>> Cheers, Paul.
>>
>> =
>>
>> Groovy currently "promotes" a singleton instance of an object into an
>> array for assignments, e.g.:
>>
>> Integer[] nums = 42
>> assert nums instanceof Integer[]
>> assert nums.size() == 1
>> assert nums[0] instanceof Integer
>>
>> This aligns with how Groovy behaves if you try to call `.each{}` on a
>> non-aggregate. It treats it like a singleton collection and "iterates" over
>> the one item.
>>
>> The existing behavior also currently works for singleton Closures:
>>
>> Closure[] fns0 = { }
>> assert fns0 instanceof Closure[]
>> assert fns0.size() == 1
>> assert fns0[0] instanceof Closure
>>
>> To add support for Java array notation, we will need to partially disable
>> this behavior. The proposed change involves smart parsing, e.g. it will
>> distinguish cases which must be an array and cases which must be a closure
>> but there are some degenerate edge cases which will become breaking changes.
>>
>> The case with the empty closure above will no longer work, instead you
>> will get this behavior, i.e. an empty array is given precedence over an
>> empty closure:
>>
>> Closure[] fns1 = { }
>> assert fns1 instanceof Closure[]
>> assert fns1.size() == 0
>>
>> To get the old behavior back you have a couple of options. Firstly, you
>> can provide the explicit closure argument delimiter:
>>
>> Closure[] fns2 = { -> } // can't be an array
>> assert fns2 instanceof Closure[]
>> assert fns2.size() == 1
>> assert fns2[0] instanceof Closure
>>
>> Or don't rely on singleton promotion and explicitly provide also the
>> array curly braces:
>>
>> Closure[] fns3 = { { } }
>> assert fns3 instanceof Closure[]
>> assert fns3.size() == 1
>> assert fns3[0] instanceof Closure
>>
>> Similarly, for the case of the identity closure:
>>
>> Closure[] fns4 = { it }
>>
>> Previously this worked but under this proposal will give:
>>
>> groovy.lang.MissingPropertyException: No such property: it ...
>>
>> Your options are to add the ext

Re: [Poll] About supporting Java-like array

2018-04-29 Thread Paul King
Yes, what you suggested is supported and indeed the preferred way.
The `as int[]` is only needed if you have def at the front, e.g.:

def fibs = [1, 1, 2, 3, 5, 8] as int[]

Cheers, Paul.

On Mon, Apr 30, 2018 at 7:54 AM, Keith Suderman <suder...@anc.org> wrote:

> I am always +1 on supporting Java syntax when practical.
>
> On Apr 29, 2018, at 5:17 PM, MG <mg...@arscreat.com> wrote:
>
> 2) I feel  { { } } being interpreted as an array containing an empty
> closure is confusing, i.e. not least surprise. I would rather not see it
> cut it so close with regards to what the Parrot parser can handle
> syntax-wise. What do others think ?
>
>
> I don't like it either, but I would be willing to live with it since I'll
> never generate something like that myself.
>
>
> 3) After introducing this syntax extension, what will be considered the
> "Groovy way" of initializing an array in the future ? Is it still
> final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]
> or
> final int[] a = { 1, 1, 2, 3, 5, 8 }
> ?
>
>
> While we are at it, could we just do:
>
> int[] a = [ 1, 1, 2, 3, 5, 8 ]
>
> without the "as int[]" at the end?  That would seem to be the "Grooviest"
> way IMO.
>
> Cheers,
> Keith
>
>
> In the 2nd case I would be worried that the core Groovy syntax becomes all
> over the place over time, same as with the new Java lambda syntax (though
> less pronounced, since using/initializing arrays is typically rare).
>
> 4) I am not too worried about the breaking edge cases, because I feel they
> are quite rare in practice, the compiler catches them, and they are easy to
> fix.
>
> Cheers,
> mg
>
>
>
> On 29.04.2018 15:29, Paul King wrote:
>
> +1
>
> For completeness, I added some more details about the breaking changes and
> workarounds into the issue - included below for easy reading.
>
> Cheers, Paul.
>
> =
>
> Groovy currently "promotes" a singleton instance of an object into an
> array for assignments, e.g.:
>
> Integer[] nums = 42
> assert nums instanceof Integer[]
> assert nums.size() == 1
> assert nums[0] instanceof Integer
>
> This aligns with how Groovy behaves if you try to call `.each{}` on a
> non-aggregate. It treats it like a singleton collection and "iterates" over
> the one item.
>
> The existing behavior also currently works for singleton Closures:
>
> Closure[] fns0 = { }
> assert fns0 instanceof Closure[]
> assert fns0.size() == 1
> assert fns0[0] instanceof Closure
>
> To add support for Java array notation, we will need to partially disable
> this behavior. The proposed change involves smart parsing, e.g. it will
> distinguish cases which must be an array and cases which must be a closure
> but there are some degenerate edge cases which will become breaking changes.
>
> The case with the empty closure above will no longer work, instead you
> will get this behavior, i.e. an empty array is given precedence over an
> empty closure:
>
> Closure[] fns1 = { }
> assert fns1 instanceof Closure[]
> assert fns1.size() == 0
>
> To get the old behavior back you have a couple of options. Firstly, you
> can provide the explicit closure argument delimiter:
>
> Closure[] fns2 = { -> } // can't be an array
> assert fns2 instanceof Closure[]
> assert fns2.size() == 1
> assert fns2[0] instanceof Closure
>
> Or don't rely on singleton promotion and explicitly provide also the array
> curly braces:
>
> Closure[] fns3 = { { } }
> assert fns3 instanceof Closure[]
> assert fns3.size() == 1
> assert fns3[0] instanceof Closure
>
> Similarly, for the case of the identity closure:
>
> Closure[] fns4 = { it }
>
> Previously this worked but under this proposal will give:
>
> groovy.lang.MissingPropertyException: No such property: it ...
>
> Your options are to add the extra array braces as per above, or use
> explicit params, e.g.:
>
> Closure[] fns5 = { it -> it }
> assert fns5 instanceof Closure[]
> assert fns5.size() == 1
> assert fns5[0] instanceof Closure
>
> Alternatively, for this special case you have the following additional
> option:
>
> Closure[] fns6 = Closure.IDENTITY
> assert fns6 instanceof Closure[]
> assert fns6.size() == 1
> assert fns6[0] instanceof Closure
>
> There are other cases as well, e.g. this code which currently creates a
> closure array containing a closure returning the integer 0:
>
> Closure[] fns7 = { 0 }
>
> will no longer be supported and will fail with:
>
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object '0' with class 'java.lang.Integer' to class 'groovy.lang.C

Re: [Poll] About supporting Java-like array

2018-04-29 Thread Paul King
The preferred Groovy syntax would probably still remain:

int[] fibs = [1, 1, 2, 3, 5, 8]

Cheers, Paul.

On Mon, Apr 30, 2018 at 7:17 AM, MG <mg...@arscreat.com> wrote:

> After thinking about this some more for the last weeks
> +1 with asterisk
> from my side:
>
> 1) I am always for being as Java compatible as possible (though I see that
> this might not be feasible in all cases in the future, due to Java changing
> at a much faster pace and with more syntax changes now than before;
> example: Java considered naming the new "var" keword "def", which is
> similar to but not the same as Java-var in Groovy...)
>
> 2) I feel  { { } } being interpreted as an array containing an empty
> closure is confusing, i.e. not least surprise. I would rather not see it
> cut it so close with regards to what the Parrot parser can handle
> syntax-wise. What do others think ?
>
> 3) After introducing this syntax extension, what will be considered the
> "Groovy way" of initializing an array in the future ? Is it still
> final int[] a = [ 1, 1, 2, 3, 5, 8 ] as int[]
> or
> final int[] a = { 1, 1, 2, 3, 5, 8 }
> ?
> In the 2nd case I would be worried that the core Groovy syntax becomes all
> over the place over time, same as with the new Java lambda syntax (though
> less pronounced, since using/initializing arrays is typically rare).
>
> 4) I am not too worried about the breaking edge cases, because I feel they
> are quite rare in practice, the compiler catches them, and they are easy to
> fix.
>
> Cheers,
> mg
>
>
>
>
> On 29.04.2018 15:29, Paul King wrote:
>
> +1
>
> For completeness, I added some more details about the breaking changes and
> workarounds into the issue - included below for easy reading.
>
> Cheers, Paul.
>
> =
>
> Groovy currently "promotes" a singleton instance of an object into an
> array for assignments, e.g.:
>
> Integer[] nums = 42
> assert nums instanceof Integer[]
> assert nums.size() == 1
> assert nums[0] instanceof Integer
>
> This aligns with how Groovy behaves if you try to call `.each{}` on a
> non-aggregate. It treats it like a singleton collection and "iterates" over
> the one item.
>
> The existing behavior also currently works for singleton Closures:
>
> Closure[] fns0 = { }
> assert fns0 instanceof Closure[]
> assert fns0.size() == 1
> assert fns0[0] instanceof Closure
>
> To add support for Java array notation, we will need to partially disable
> this behavior. The proposed change involves smart parsing, e.g. it will
> distinguish cases which must be an array and cases which must be a closure
> but there are some degenerate edge cases which will become breaking changes.
>
> The case with the empty closure above will no longer work, instead you
> will get this behavior, i.e. an empty array is given precedence over an
> empty closure:
>
> Closure[] fns1 = { }
> assert fns1 instanceof Closure[]
> assert fns1.size() == 0
>
> To get the old behavior back you have a couple of options. Firstly, you
> can provide the explicit closure argument delimiter:
>
> Closure[] fns2 = { -> } // can't be an array
> assert fns2 instanceof Closure[]
> assert fns2.size() == 1
> assert fns2[0] instanceof Closure
>
> Or don't rely on singleton promotion and explicitly provide also the array
> curly braces:
>
> Closure[] fns3 = { { } }
> assert fns3 instanceof Closure[]
> assert fns3.size() == 1
> assert fns3[0] instanceof Closure
>
> Similarly, for the case of the identity closure:
>
> Closure[] fns4 = { it }
>
> Previously this worked but under this proposal will give:
>
> groovy.lang.MissingPropertyException: No such property: it ...
>
> Your options are to add the extra array braces as per above, or use
> explicit params, e.g.:
>
> Closure[] fns5 = { it -> it }
> assert fns5 instanceof Closure[]
> assert fns5.size() == 1
> assert fns5[0] instanceof Closure
>
> Alternatively, for this special case you have the following additional
> option:
>
> Closure[] fns6 = Closure.IDENTITY
> assert fns6 instanceof Closure[]
> assert fns6.size() == 1
> assert fns6[0] instanceof Closure
>
> There are other cases as well, e.g. this code which currently creates a
> closure array containing a closure returning the integer 0:
>
> Closure[] fns7 = { 0 }
>
> will no longer be supported and will fail with:
>
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object '0' with class 'java.lang.Integer' to class 'groovy.lang.Closure'
> The solutions are similar to previously (explicit delimiter):
>
> Closure[] fns8 = { -> 0 }
>
&

Re: [Poll] About supporting Java-like array

2018-04-29 Thread Paul King
+1

For completeness, I added some more details about the breaking changes and
workarounds into the issue - included below for easy reading.

Cheers, Paul.

=

Groovy currently "promotes" a singleton instance of an object into an array
for assignments, e.g.:

Integer[] nums = 42
assert nums instanceof Integer[]
assert nums.size() == 1
assert nums[0] instanceof Integer

This aligns with how Groovy behaves if you try to call `.each{}` on a
non-aggregate. It treats it like a singleton collection and "iterates" over
the one item.

The existing behavior also currently works for singleton Closures:

Closure[] fns0 = { }
assert fns0 instanceof Closure[]
assert fns0.size() == 1
assert fns0[0] instanceof Closure

To add support for Java array notation, we will need to partially disable
this behavior. The proposed change involves smart parsing, e.g. it will
distinguish cases which must be an array and cases which must be a closure
but there are some degenerate edge cases which will become breaking changes.

The case with the empty closure above will no longer work, instead you will
get this behavior, i.e. an empty array is given precedence over an empty
closure:

Closure[] fns1 = { }
assert fns1 instanceof Closure[]
assert fns1.size() == 0

To get the old behavior back you have a couple of options. Firstly, you can
provide the explicit closure argument delimiter:

Closure[] fns2 = { -> } // can't be an array
assert fns2 instanceof Closure[]
assert fns2.size() == 1
assert fns2[0] instanceof Closure

Or don't rely on singleton promotion and explicitly provide also the array
curly braces:

Closure[] fns3 = { { } }
assert fns3 instanceof Closure[]
assert fns3.size() == 1
assert fns3[0] instanceof Closure

Similarly, for the case of the identity closure:

Closure[] fns4 = { it }

Previously this worked but under this proposal will give:

groovy.lang.MissingPropertyException: No such property: it ...

Your options are to add the extra array braces as per above, or use
explicit params, e.g.:

Closure[] fns5 = { it -> it }
assert fns5 instanceof Closure[]
assert fns5.size() == 1
assert fns5[0] instanceof Closure

Alternatively, for this special case you have the following additional
option:

Closure[] fns6 = Closure.IDENTITY
assert fns6 instanceof Closure[]
assert fns6.size() == 1
assert fns6[0] instanceof Closure

There are other cases as well, e.g. this code which currently creates a
closure array containing a closure returning the integer 0:

Closure[] fns7 = { 0 }

will no longer be supported and will fail with:

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
object '0' with class 'java.lang.Integer' to class 'groovy.lang.Closure'
The solutions are similar to previously (explicit delimiter):

Closure[] fns8 = { -> 0 }

or (explicit outer array braces):

Closure[] fns9 = { { 0 } }


On Sun, Apr 29, 2018 at 8:37 PM, Daniel.Sun  wrote:

> Hi all,
>
>  As we all know, Java array is one of features widely applied in Java
> projects. In order to improve the compatibility with Java(Copy & Paste).
> The
> PR[1] will make Groovy support java-like array and make the differences[2]
> with Java less and less, e.g.
>
> *One-Dimensional array*
> ```
> String[] names = {'Jochen', 'Paul', 'Daniel'}
> ```
>
> *Two-Dimensional array*
> ```
> int[][] data = {
> {1, 2, 3},
> {4, 5, 6},
> {7, 8, 9},
> new int[] { 10, 11, 12 },
> {13, 14, 15}
> }
> ```
>
> *Annotation array*
> ```
> @PropertySources({
> @PropertySource("classpath:1.properties"),
> @PropertySource("file:2.properties")
> })
> public class Controller {}
> ```
>
> *More examples*
> Please see the examples on the PR page[1]
>
> *Known breaking changes*
> 1. Closure array in the dynamic mode
> Before
> ```
> Closure[] y = { {-> 1 + 1 } }
> assert y[0].call().call() == 2
> ```
> After
> ```
> Closure[] y = { {-> 1 + 1 } }
> assert y[0].call() == 2
> ```
> 2. String array in the dynamic mode
> Before
> ```
> String[] a = {}
> assert 1 == a.length
> assert a[0].contains('closure')
> ```
> After
> ```
> String[] a = {}
> assert 0 == a.length
> ```
>
>
>   If Groovy 3 supports Java-like array, what do you think about the new
> feature? Do you like it? We need your feedback. Thanks in advance!
>
> [+1] I like it
> [ 0] Not bad
> [-1] I don't like it, because...
>
> Cheers,
> Daniel.Sun
> [1] https://github.com/apache/groovy/pull/691
> [2] http://groovy-lang.org/differences.html
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>


Re: Java does not see method implemented in Groovy

2018-04-23 Thread Paul King
A bit of a long shot but does compiling the class by hand (outside gradle)
make any difference?


On Mon, Apr 23, 2018 at 8:05 PM, Schalk Cronjé  wrote:

> Hi all,
>
> I have build an hierarchy that effectively looks like:
>
> Abstract Base #1 (Java)
> ^
> |
> Abstract Base #2 (Groovy, CompileStatic)
> ^
> |
> Abstract Base #3 (Groovy, CompileStatic)
> ^
> |
> Abstract Base #4 (Groovy, CompileStatic) <- Implements methodA from
> Abstract Base #1
> ^^ ^
> || |
> ExampleG (Groovy)ExampleJ (Java)   ExampleK (Kotlin)
>
> Finally there are three examples - one each in  Groovy, Java and otlin
> example. They extend #4 with concrete classes. The Groovy and Kotlin
> examples compile fine, but the Java complains that methodA is not
> implemented. The real signature of methodA is actually
>
> SeekableByteChannel newByteChannel(Path path, Set
> options, FileAttribute[] attrs) throws IOException
>
> This could be down to what the Groovy compiler (2.4.11) has done with the
> generics, but it has me me confused. I am even more surprised that only the
> Java compiler complains and not the Kotlin compiler.  In IntelliJ this is
> not flagged up as an issue either. It only occurs when compiling the
> project with Gradle.
>
> I know my example is slightly vague, but it removes all of the noise. The
> actual code of the offending class is here ->
> https://gitlab.com/ysb33rOrg/java-nio2-providers/blob/
> development/commons-compress-provider-core/src/test/java/
> org/ysb33r/nio/provider/commons_core/examples/java/
> GzFileSystemProvider.java
>
> Now I'm hoping if anyone has seen issues like this before or have an idea
> where I can start diagnosing it.
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>
>


Re: [ANNOUNCE] Apache Groovy 3.0.0-alpha-2 released

2018-04-17 Thread Paul King
Nice work Daniel!

On Tue, Apr 17, 2018 at 3:35 PM, 孙 岚  wrote:

> Dear community,
>
> The Apache Groovy team is pleased to announce version 3.0.0-alpha-2 of
> Apache Groovy.
> Apache Groovy is a multi-facet 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 40 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318123=12342254
>
> 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] Groovy 2.5.0-rc-1 Windows Installer Released

2018-04-15 Thread Paul King
Thanks Keegan!

On Mon, Apr 16, 2018 at 5:34 AM, Keegan Witt  wrote:

> The Windows installer for Groovy 2.5.0-rc-1 is available from the usual
> place: https://bintray.com/groovy/Distributions/Windows-
> Installer/groovy-2.5.0-rc-1-installer
>
> -Keegan
>


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

2018-04-09 Thread Paul King
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.
>>
>
>


[ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

2018-04-09 Thread 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: [ANNOUNCE] Groovy 2.6.0-alpha-3 Windows Installer Released

2018-03-30 Thread Paul King
Nice work on all those installers Keegan!

On Fri, Mar 30, 2018 at 11:17 PM, Keegan Witt  wrote:

> The Windows installer for Groovy 2.6.0-alpha-3 is available from the
> usual place: https://bintray.com/groovy/Distributions/download_
> file?file_path=groovy-2.6.0-alpha-3-installer.exe
>
> -Keegan
>


Re: Why does Groovy's CliBuilder depend on apache commons-cli, which isn't included in groovy-all?

2018-03-29 Thread Paul King
The groovy-all jar doesn't bundle Groovy's optional dependencies such as:
ant, junit, bsf, commons-logging, log4j, jline, testng, xstream,
commons-cli, jansi, ivy, etc. It includes all of Groovy's modules and
embeds a small set of required dependencies for its own internal purposes
like asm and antlr and commons-cli.

This lets you write scripts or classes which also use those dependencies
directly or indirectly, e.g. hibernate uses antlr, spring uses asm and
importantly they might be different versions and that's okay.

The embedded commons-cli is used for the command-line tools (groovy,
groovyc, groovysh, groovyConsole etc.). There are other technical reasons
like classloader issues related to the approach we have taken but mostly
it's a separation of concerns issue. We might change what cli handling
package we use internally and we might supply different modules which offer
different CliBuilder implementations which might have different
dependencies. We don't want to tie all these things together. Technically,
you can use the groovyjarjarcommonscli package if you want direct access to
the commons-cli library though it's not recommended and it's not possible
via CliBuilder - it is specifically designed not to use the internal one.
In the future with JDK9/10+ we will likely not make such embedded packages
visible at all.

Long story short, add the commons-cli dependency to your project and/or
classpath. That's the correct approach.

Cheers, Paul.


On Fri, Mar 30, 2018 at 1:02 AM, Nick  wrote:

> Hello,
>
> I asked a question on stack overflow, I wonder if anyone here knows the
> answer?
>
> https://stackoverflow.com/questions/49452422/why-does-groovy
> s-clibuilder-depend-on-apache-commons-cli-which-isnt-included
>
> To quote it:
>
> > I've been attempting to use the Groovy CliBuilder, as described here:
> >
> > http://docs.groovy-lang.org/2.4.7/html/gapi/groovy/util/CliBuilder.html
> >
> > However, it depends on classes missing from groovy-all-2.4.7,
> specifically those in Apache's commons-cli library.
> >
> > Ok, so I could add that dependency. But I find there is what looks like
> a version of the Apache CliBuilder class bundled in groovy-all in the
> groovyjarjarcommonscli package!
> >
> > Firstly, why bundle that at all?
> >
> > Secondly, why not use it to back Groovy's CliBuilder implementation?
> >
> > Thirdly, can I rely groovyjarjarcommonscli being there for use in the
> future?
>
>
> Thanks!
>
> Nick
>
>


[ANNOUNCE] Apache Groovy 2.4.15 released

2018-03-27 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.4.15 of Apache Groovy.
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

This release is a maintenance release of the GROOVY_2_4_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 6 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12342853

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
Jars are also available within the major binary repositories.
We would like to thank all people who contributed to this release.

We welcome your help and feedback. 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: JDK 10: Use of var over def?

2018-03-25 Thread Paul King
For the majority of cases, you will be able to conceptually think of it as
if the declaration type of the LHS is the inferred type of the RHS.
Until we have thought about non-denotable types etc. a bit more, I don't
want to preempt whether a more sophisticated conceptual model will
sometimes be needed.
Also, note that it isn't Object in your example but SomeTestClass$1 or
something like that.

Cheers, Paul.

On Sun, Mar 25, 2018 at 12:30 AM, MG <mg...@arscreat.com> wrote:

> There is no "var" in my example because it is currently valid Groovy code,
> so I already had to do the var -> typeof(RHS) substitution in the line
> "SonOfFoo f = new SonOfFoo(21)". I maybe should have made that more
> explicit :-)
> The reason I used currently valid Groovy was, that the point I am trying
> to make is: Why should var not just become typeof(RHS), while all the rest
> stays the same ? That should give us Java-like type safety, with some added
> Groovy goodness...
>
> Your example as currently working Groovy (JUnit) code through only
> replacing var with its RHS type:
>
> static class Main {}
> @Test@Ignore@CompileStaticvoid main() {
>   // mg: was "var x = new Object() {"  Object x = new Object() {
> public void myMethod() { System.out.println(new Date()); }
>   };
>   x.myMethod(); // okay because the inferred type is the AIC  // mg: Was "var 
> y = new Main();"  Main y = new Main();
>   y = new Main() { // reassignment okay because new type is subclass of 
> inferred typepublic void myMethod() { System.out.println(new Date());}
>   };
>
>   // mg: Works  y.myMethod(); // <=== error: cannot find symbol  // mg: If 
> commented in, fails (as expected) with "Cannot assign value of type Integer 
> to variable of type Main"//y = new Integer(3); // <=== error: 
> incompatible types: Integer cannot be converted to Main}
>
> Cheers,
> mg
>
>
>
>
> On 24.03.2018 13:08, Paul King wrote:
>
> I don't see a var in your example?
>
> Basically, we can use def and have flow typing (which would be the
> behavior if we make var always an alias for def) or we can behave like Java:
>
> // Java
> import java.util.Date;
>
> public class Main {
> public static void main(String[] args) {
> var x = new Object() {
> public void myMethod() { System.out.println(new Date());}
> };
> x.myMethod(); // okay because the inferred type is the AIC
> var y = new Main();
> y = new Main() { // reassignment okay because new type is subclass of
> inferred type
> public void myMethod() { System.out.println(new Date());}
> };
>
> // y.myMethod(); // <=== error: cannot find symbol
>   // symbol: method myMethod()
>   // location: variable y of type Main
>
> // y = new Integer(3); // <=== error: incompatible types: Integer cannot
> be converted to Main
> }
> }
>
> which effectively means that we infer as we do now but no flow typing.
> Conceptually, you may think that in the above Java example that var y has
> type Main (typeof RHS) but that isn't reflected in the bytecode in the same
> way that a type for a field or parameter would be reflected, so it's much
> more a concept that the compiler knows about rather than a concept that the
> bytecode knows about. Currently flow typing allows both the above "error"
> lines to succeed. But to behave like Java, we need both to fail.
>
> Cheers, Paul.
>
>
> On Sat, Mar 24, 2018 at 3:14 AM, MG <mg...@arscreat.com> wrote:
>
>> Hi Paul,
>>
>> wouldn't it make sense to combine flow typing with  var x = RHS  being
>> identical to  typeof(RHS) x = RHS  :
>>
>> @Canonicalstatic class Foo {
>>   int x}
>> @InheritConstructorsstatic class SonOfFoo extends Foo {
>>   int sonOfFooMethod() { 2*x }
>> }
>>
>> @Test@Ignore@CompileStaticvoid flowTypedVar() {
>>   SonOfFoo f = new SonOfFoo(21)
>>   //f = new Foo(-1) // compile time fails with "Groovyc: [Static type 
>> checking] - Cannot assign value of type groovy.GroovyGeneralSpike$Foo to 
>> variable of type groovy.GroovyGeneralSpike$SonOfFoo"  //f.sonOfFooMethod()   
>> // compile time fails with "Groovyc: [Static type checking] - Cannot find 
>> matching method groovy.GroovyGeneralSpike$Foo#sonOfFooMethod()."  if(f 
>> instanceof SonOfFoo) {
>> println f.sonOfFooMethod()  // works because of flow typing  }
>> }
>>
>> Cheers,
>> mg
>>
>>
>>
>>
>> On 23.03.2018 15:42, Paul King wrote:
>>
>> The Parrot parser already has support for this at the grammar level but
>> we regard some of the current implementation details as e

Re: JDK 10: Use of var over def?

2018-03-24 Thread Paul King
I don't see a var in your example?

Basically, we can use def and have flow typing (which would be the behavior
if we make var always an alias for def) or we can behave like Java:

// Java
import java.util.Date;

public class Main {
public static void main(String[] args) {
var x = new Object() {
public void myMethod() { System.out.println(new Date());}
};
x.myMethod(); // okay because the inferred type is the AIC
var y = new Main();
y = new Main() { // reassignment okay because new type is subclass of
inferred type
public void myMethod() { System.out.println(new Date());}
};

// y.myMethod(); // <=== error: cannot find symbol
  // symbol: method myMethod()
  // location: variable y of type Main

// y = new Integer(3); // <=== error: incompatible types: Integer cannot be
converted to Main
}
}

which effectively means that we infer as we do now but no flow typing.
Conceptually, you may think that in the above Java example that var y has
type Main (typeof RHS) but that isn't reflected in the bytecode in the same
way that a type for a field or parameter would be reflected, so it's much
more a concept that the compiler knows about rather than a concept that the
bytecode knows about. Currently flow typing allows both the above "error"
lines to succeed. But to behave like Java, we need both to fail.

Cheers, Paul.


On Sat, Mar 24, 2018 at 3:14 AM, MG <mg...@arscreat.com> wrote:

> Hi Paul,
>
> wouldn't it make sense to combine flow typing with  var x = RHS  being
> identical to  typeof(RHS) x = RHS  :
>
> @Canonicalstatic class Foo {
>   int x}
> @InheritConstructorsstatic class SonOfFoo extends Foo {
>   int sonOfFooMethod() { 2*x }
> }
>
> @Test@Ignore@CompileStaticvoid flowTypedVar() {
>   SonOfFoo f = new SonOfFoo(21)
>   //f = new Foo(-1) // compile time fails with "Groovyc: [Static type 
> checking] - Cannot assign value of type groovy.GroovyGeneralSpike$Foo to 
> variable of type groovy.GroovyGeneralSpike$SonOfFoo"  //f.sonOfFooMethod()   
> // compile time fails with "Groovyc: [Static type checking] - Cannot find 
> matching method groovy.GroovyGeneralSpike$Foo#sonOfFooMethod()."  if(f 
> instanceof SonOfFoo) {
> println f.sonOfFooMethod()  // works because of flow typing  }
> }
>
> Cheers,
> mg
>
>
>
>
> On 23.03.2018 15:42, Paul King wrote:
>
> The Parrot parser already has support for this at the grammar level but we
> regard some of the current implementation details as experimental.
>
> At the moment it is almost just an alias for "def" but discussions have
> been around whether we can make the behavior closer to Java when used
> within static Groovy code. We haven't defined exactly what this would mean
> yet but roughly I suspect it could mean the same inferencing as now but
> without flow typing.
>
> Cheers, Paul.
>
>
> On Fri, Mar 23, 2018 at 10:12 PM, Merlin Beedell <mbeed...@cryoserver.com>
> wrote:
>
>> I see that the newly release JDK 10 now supports the “var” declaration
>> for local variables where the type can clearly be inferred from its
>> initialiser:
>>
>>
>>
>> http://openjdk.java.net/jeps/286
>>
>>
>>
>> I note that Groovy’s “def” syntax (among others) was mentioned but
>> rejected.
>>
>>
>>
>> Would Groovy move to support this syntax in the same way (support ‘var’
>> only for Type Safe inferred declarations) or as a general alias to the
>> “def” keyword?
>>
>>
>>
>> JDK 10 also has support for “docker” containers.  The ecosystem has
>> certainly shifted!
>>
>>
>>
>> Merlin Beedell
>>
>>
>>
>
>
>


Re: JDK 10: Use of var over def?

2018-03-23 Thread Paul King
The Parrot parser already has support for this at the grammar level but we
regard some of the current implementation details as experimental.

At the moment it is almost just an alias for "def" but discussions have
been around whether we can make the behavior closer to Java when used
within static Groovy code. We haven't defined exactly what this would mean
yet but roughly I suspect it could mean the same inferencing as now but
without flow typing.

Cheers, Paul.


On Fri, Mar 23, 2018 at 10:12 PM, Merlin Beedell 
wrote:

> I see that the newly release JDK 10 now supports the “var” declaration for
> local variables where the type can clearly be inferred from its initialiser:
>
>
>
> http://openjdk.java.net/jeps/286
>
>
>
> I note that Groovy’s “def” syntax (among others) was mentioned but
> rejected.
>
>
>
> Would Groovy move to support this syntax in the same way (support ‘var’
> only for Type Safe inferred declarations) or as a general alias to the
> “def” keyword?
>
>
>
> JDK 10 also has support for “docker” containers.  The ecosystem has
> certainly shifted!
>
>
>
> Merlin Beedell
>
>
>


Re: Groovy 3 lambda, method reference, default methods

2018-03-22 Thread Paul King
Currently, you can switch off the Antlr parser in Groovy 3.0 by setting the
antlr4 switch to false. We might deem that an implementation detail rather
than a supported feature. In any case, we will likely drop that fairly
soon, e.g. Groovy 3.1 (unplanned version number but assuming that's the
next version).



On Thu, Mar 22, 2018 at 10:59 PM, Daniil Ovchinnikov <
daniil.ovchinni...@jetbrains.com> wrote:

> It will be deduced it from library with a single switch to use Parrot in
> 2.6.
> There is no other reason not to use library version, since Groovy can’t
> cross compile classes to run with old Groovy versions.
>
> —
>
> Daniil Ovchinnikov
> Software Developer
> JetBrains
> jetbrains.com
> “Drive to develop”
>
>
>
> On 22 Mar 2018, at 15:42, mg  wrote:
>
> Will Groovy 3.0 feature support be configurable (as for Java), or will it
> be deduced from Groovy libs used, ... ?
>
>  Ursprüngliche Nachricht 
> Von: Daniil Ovchinnikov 
> Datum: 22.03.18 12:41 (GMT+01:00)
> An: users@groovy.apache.org
> Betreff: Re: Groovy 3 lambda, method reference, default methods
>
> IntelliJ will support Groovy 3 but with own parser.
>
> - using the parser provided by Groovy library restricts support to that
> library version;
> - compiler parsers are usually non-recoverable, but in IntelliJ we want to
> provide ability to work with broken code as much as possible, so we have
> own parsers for (almost) each language.
>
> —
>
> Daniil Ovchinnikov
> Software Developer
> JetBrains
> jetbrains.com
> “Drive to develop”
>
>
>
> > On 21 Mar 2018, at 22:30, mg  wrote:
> >
> > I guess the Groovy 3.0/3.0-- (aka 2.6) syntax elements support will be
> switchable in IntelliJ, anything else would make little sense to me.
> > But we have the expert on this mailing list, who should be able to tell
> us... :-)
> > mg
> >
> >  Ursprüngliche Nachricht 
> > Von: "Daniel.Sun" 
> > Datum: 21.03.18 17:10 (GMT+01:00)
> > An: us...@groovy.incubator.apache.org
> > Betreff: RE: Groovy 3 lambda, method reference, default methods
> >
> > You can write Java8 style code(e.g. lambda, method/constructor reference,
> > etc.) when Parrot parser is enabled :-)
> > See https://github.com/danielsun1106/groovy-parser
> >
> >
> > > Is there then a major difference in language between 2.6+Parrot and
> 3.0?
> >
> > 3.0 enables Parrot parser by default, so no differences.
> >
> >
> > > I wonder if the IntelliJ support ticket should be updated to say
> support
> > > new language features in Groovy 2.6 as well?
> >
> > I see the title contains "Groovy 3", so I am not sure if it will support
> 2.6
> >
> >
> > Cheers,
> > Daniel.Sun
> >
> >
> >
> >
> > --
> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>
>
>


Re: Upgrade Groovy jar - can't start tomcat

2018-03-21 Thread Paul King
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  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 :
>
>>
>>
>> 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: traits fields initialization order ?

2018-03-10 Thread Paul King
There is a known bug in trait initialization for final fields:

https://issues.apache.org/jira/browse/GROOVY-8281

It's on my list to fix before 2.5.0 final. Happy for any assistance.

Cheers, Paul.


On Sun, Mar 11, 2018 at 6:37 AM, MG  wrote:

> Hi,
>
> I recently refactored the reflection code of my framework to support using
> traits to share fields. The shared fields are initialized during field
> declaration (i.e. not in a ctor) for user convenience (they represent
> columns in a table). In this particular case, fields needed to be passed as
> parameters to to other field's ctors. In this case the problem is, that the
> fields passed to other fields ctors seem to alwys be null. The same code
> constructs have been working for years when using them directly inside a
> class.
>
> Questions:
>
>1.  What is the expected behavior in this case ? Should this work in
>traits ?
>2. If this is not a bug in Groovy: What is the best workaround ? I
>only had very little time to work on this last week, so I used a @Memoized
>helper method whose return value is used in both the field initializations
>- works, but a pretty terrible solution and user experience.
>I just did a quick spike at home using @Lazy on one field: This seems
>to work, but not, if combined with final - so the field could be reassigned
>(which I don't want) unless the framework user introduces a shared @Lazy
>"hidden" private helper field (similar to my @Memoized method).
>3. In general: What is the exact order that fields get initialized in
>Groovy - and is this behavior expected to change in the future ?
>
> Cheers,
> mg
>
>
>
>


Re: Unexpected compilation error with 2.4.14

2018-03-06 Thread Paul King
I created https://issues.apache.org/jira/browse/GROOVY-8494 to track this.

Cheers, Paul.

On Wed, Mar 7, 2018 at 10:34 AM, Paul King <pa...@asert.com.au> wrote:

> Okay, I can reproduce now on 2.4.14 and latest 2_4_X using 1.8.0_161.
> No problem on that JVM version with 2.5.0-beta-3 or 2_5_X with the
> cherry-picked change or 2.6.0-alpha-3 or master.
>
> Cheers, Paul.
>
> On Wed, Mar 7, 2018 at 10:13 AM, Paul King <pa...@asert.com.au> wrote:
>
>> I used 1.8.0_161 but so far have only pasted the problematic line into
>> Groovy Console and run it.
>>
>> Jochen, your change did seem to be missing on 2_5_X but was on the other
>> branches. I just cherry picked it onto 2_5_X.
>> I think we need to close off GROOVY-8338 and clone a new issue with a new
>> reproducer.
>>
>> Cheers, Paul.
>>
>>
>>
>>
>> On Wed, Mar 7, 2018 at 9:37 AM, Jochen Theodorou <blackd...@gmx.org>
>> wrote:
>>
>>> On 06.03.2018 13:23, Andres Almiray wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I'm in the process of updating the Griffon build to use Groovy 2.4.14
>>>> and encountered a weird problem in one of the tests
>>>> https://github.com/griffon/griffon/blob/development/subproje
>>>> cts/griffon-javafx-groovy/src/test/groovy/griffon/javafx/Gri
>>>> ffonFXCollectionsExtensionTest.groovy#L78
>>>>
>>>> The test runs fine with 2.413 but generates the following stacktrace
>>>> with 2.4.14
>>>>
>>>> java.lang.VerifyError: (class: java_util_function_Function$identity,
>>>> method: callStatic signature: 
>>>> (Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;)
>>>> Illegal type in constant pool
>>>>
>>> [...]
>>>
>>>> at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts.
>>>> defineClassAndGetConstructor(ClassLoaderForClassArtifacts.java:82)
>>>> at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compi
>>>> leStaticMethod(CallSiteGenerator.java:262)
>>>> at org.codehaus.groovy.reflection.CachedMethod.createStaticMeta
>>>> MethodSite(CachedMethod.java:295)
>>>> at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.cr
>>>> eateStaticMetaMethodSite(StaticMetaMethodSite.java:114)
>>>>
>>> [...]
>>>
>>> this is clearly during callsite generation. The generated helper class
>>> to realize the static method call is invalid. I would now go and change the
>>> code to write those classes to disc and then I can look with a "proper"
>>> tool at it. Or I would at least put the ASM verify into the queue
>>>
>>> The "faulty" line is
>>>>
>>>> Function<Integer, Integer> function = Function.identity()
>>>>
>>>> I'm baffled by this error as java.util.function.Function is a core JDK
>>>> type.
>>>>
>>>> Environment
>>>>
>>>> 
>>>> Gradle 4.6
>>>> 
>>>>
>>>> Build time:   2018-02-28 13:36:36 UTC
>>>> Revision: 8fa6ce7945b640e6168488e4417f9bb96e4ab46c
>>>>
>>>> Groovy:   2.4.12
>>>> Ant:  Apache Ant(TM) version 1.9.9 compiled on February 2 2017
>>>> JVM:  1.8.0_162 (Oracle Corporation 25.162-b12)
>>>> OS:   Mac OS X 10.12.5 x86_64
>>>>
>>>
>>> It is also possible that the code is valid on one JVM and not on
>>> another. 1.8.0_162 seems to be the newest JDK 1.8. Did you try that exact
>>> java version as well Paul?
>>>
>>> Steps to reproduce:
>>>>
>>>> $ git clone https://github.com/griffon/griffon.git
>>>> $ cd griffon
>>>> // update gradle.properties with groovyVersion = 2.4.14
>>>> $ ./gradlew :griffon-javafx-groovy:test
>>>>
>>>
>>> updating gradle.properties is not required, that is set to 2.4.14
>>> already. Instead you should remove the @Ignore in
>>> https://github.com/griffon/griffon/blob/development/subproje
>>> cts/griffon-javafx-groovy/src/test/groovy/griffon/javafx/Gri
>>> ffonFXCollectionsExtensionTest.groovy#L78
>>>
>>> and this also fails with update 152, which reduces my theory, that is
>>> depending on the JVM version
>>>
>>

Re: Unexpected compilation error with 2.4.14

2018-03-06 Thread Paul King
Okay, I can reproduce now on 2.4.14 and latest 2_4_X using 1.8.0_161.
No problem on that JVM version with 2.5.0-beta-3 or 2_5_X with the
cherry-picked change or 2.6.0-alpha-3 or master.

Cheers, Paul.

On Wed, Mar 7, 2018 at 10:13 AM, Paul King <pa...@asert.com.au> wrote:

> I used 1.8.0_161 but so far have only pasted the problematic line into
> Groovy Console and run it.
>
> Jochen, your change did seem to be missing on 2_5_X but was on the other
> branches. I just cherry picked it onto 2_5_X.
> I think we need to close off GROOVY-8338 and clone a new issue with a new
> reproducer.
>
> Cheers, Paul.
>
>
>
>
> On Wed, Mar 7, 2018 at 9:37 AM, Jochen Theodorou <blackd...@gmx.org>
> wrote:
>
>> On 06.03.2018 13:23, Andres Almiray wrote:
>>
>>> Hello everyone,
>>>
>>> I'm in the process of updating the Griffon build to use Groovy 2.4.14
>>> and encountered a weird problem in one of the tests
>>> https://github.com/griffon/griffon/blob/development/subproje
>>> cts/griffon-javafx-groovy/src/test/groovy/griffon/javafx/Gri
>>> ffonFXCollectionsExtensionTest.groovy#L78
>>>
>>> The test runs fine with 2.413 but generates the following stacktrace
>>> with 2.4.14
>>>
>>> java.lang.VerifyError: (class: java_util_function_Function$identity,
>>> method: callStatic signature: 
>>> (Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;)
>>> Illegal type in constant pool
>>>
>> [...]
>>
>>> at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts.
>>> defineClassAndGetConstructor(ClassLoaderForClassArtifacts.java:82)
>>> at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compi
>>> leStaticMethod(CallSiteGenerator.java:262)
>>> at org.codehaus.groovy.reflection.CachedMethod.createStaticMeta
>>> MethodSite(CachedMethod.java:295)
>>> at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.cr
>>> eateStaticMetaMethodSite(StaticMetaMethodSite.java:114)
>>>
>> [...]
>>
>> this is clearly during callsite generation. The generated helper class to
>> realize the static method call is invalid. I would now go and change the
>> code to write those classes to disc and then I can look with a "proper"
>> tool at it. Or I would at least put the ASM verify into the queue
>>
>> The "faulty" line is
>>>
>>> Function<Integer, Integer> function = Function.identity()
>>>
>>> I'm baffled by this error as java.util.function.Function is a core JDK
>>> type.
>>>
>>> Environment
>>>
>>> 
>>> Gradle 4.6
>>> 
>>>
>>> Build time:   2018-02-28 13:36:36 UTC
>>> Revision: 8fa6ce7945b640e6168488e4417f9bb96e4ab46c
>>>
>>> Groovy:   2.4.12
>>> Ant:  Apache Ant(TM) version 1.9.9 compiled on February 2 2017
>>> JVM:  1.8.0_162 (Oracle Corporation 25.162-b12)
>>> OS:   Mac OS X 10.12.5 x86_64
>>>
>>
>> It is also possible that the code is valid on one JVM and not on another.
>> 1.8.0_162 seems to be the newest JDK 1.8. Did you try that exact java
>> version as well Paul?
>>
>> Steps to reproduce:
>>>
>>> $ git clone https://github.com/griffon/griffon.git
>>> $ cd griffon
>>> // update gradle.properties with groovyVersion = 2.4.14
>>> $ ./gradlew :griffon-javafx-groovy:test
>>>
>>
>> updating gradle.properties is not required, that is set to 2.4.14
>> already. Instead you should remove the @Ignore in
>> https://github.com/griffon/griffon/blob/development/subproje
>> cts/griffon-javafx-groovy/src/test/groovy/griffon/javafx/Gri
>> ffonFXCollectionsExtensionTest.groovy#L78
>>
>> and this also fails with update 152, which reduces my theory, that is
>> depending on the JVM version
>>
>> Using 2.5.0-beta-3:  712 tests completed, 208 failed.
>> Using 2.6.0-alpha-2: 712 tests completed, 52 failed
>> Using 2.6.0-alpha-3: fails with
>>
>>>  Could not find groovy-all.jar (org.codehaus.groovy:groovy-al
>>> l:2.6.0-alpha-3).
>>>   Searched in the following locations:
>>>   https://jcenter.bintray.com/org/codehaus/groovy/groovy-all/2
>>> .6.0-alpha-3/groovy-all-2.6.0-alpha-3.jar
>>>
>>
>> did not try 3.0.0-alpha-1, because it is from Nov. last year and did not
>> have a chang

Re: Unexpected compilation error with 2.4.14

2018-03-06 Thread Paul King
I used 1.8.0_161 but so far have only pasted the problematic line into
Groovy Console and run it.

Jochen, your change did seem to be missing on 2_5_X but was on the other
branches. I just cherry picked it onto 2_5_X.
I think we need to close off GROOVY-8338 and clone a new issue with a new
reproducer.

Cheers, Paul.




On Wed, Mar 7, 2018 at 9:37 AM, Jochen Theodorou  wrote:

> On 06.03.2018 13:23, Andres Almiray wrote:
>
>> Hello everyone,
>>
>> I'm in the process of updating the Griffon build to use Groovy 2.4.14 and
>> encountered a weird problem in one of the tests
>> https://github.com/griffon/griffon/blob/development/subproje
>> cts/griffon-javafx-groovy/src/test/groovy/griffon/javafx/Gri
>> ffonFXCollectionsExtensionTest.groovy#L78
>>
>> The test runs fine with 2.413 but generates the following stacktrace with
>> 2.4.14
>>
>> java.lang.VerifyError: (class: java_util_function_Function$identity,
>> method: callStatic signature: 
>> (Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;)
>> Illegal type in constant pool
>>
> [...]
>
>> at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts.
>> defineClassAndGetConstructor(ClassLoaderForClassArtifacts.java:82)
>> at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compi
>> leStaticMethod(CallSiteGenerator.java:262)
>> at org.codehaus.groovy.reflection.CachedMethod.createStaticMeta
>> MethodSite(CachedMethod.java:295)
>> at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.cr
>> eateStaticMetaMethodSite(StaticMetaMethodSite.java:114)
>>
> [...]
>
> this is clearly during callsite generation. The generated helper class to
> realize the static method call is invalid. I would now go and change the
> code to write those classes to disc and then I can look with a "proper"
> tool at it. Or I would at least put the ASM verify into the queue
>
> The "faulty" line is
>>
>> Function function = Function.identity()
>>
>> I'm baffled by this error as java.util.function.Function is a core JDK
>> type.
>>
>> Environment
>>
>> 
>> Gradle 4.6
>> 
>>
>> Build time:   2018-02-28 13:36:36 UTC
>> Revision: 8fa6ce7945b640e6168488e4417f9bb96e4ab46c
>>
>> Groovy:   2.4.12
>> Ant:  Apache Ant(TM) version 1.9.9 compiled on February 2 2017
>> JVM:  1.8.0_162 (Oracle Corporation 25.162-b12)
>> OS:   Mac OS X 10.12.5 x86_64
>>
>
> It is also possible that the code is valid on one JVM and not on another.
> 1.8.0_162 seems to be the newest JDK 1.8. Did you try that exact java
> version as well Paul?
>
> Steps to reproduce:
>>
>> $ git clone https://github.com/griffon/griffon.git
>> $ cd griffon
>> // update gradle.properties with groovyVersion = 2.4.14
>> $ ./gradlew :griffon-javafx-groovy:test
>>
>
> updating gradle.properties is not required, that is set to 2.4.14 already.
> Instead you should remove the @Ignore in https://github.com/griffon/gri
> ffon/blob/development/subprojects/griffon-javafx-groovy/src/
> test/groovy/griffon/javafx/GriffonFXCollectionsExtensionTest.groovy#L78
>
> and this also fails with update 152, which reduces my theory, that is
> depending on the JVM version
>
> Using 2.5.0-beta-3:  712 tests completed, 208 failed.
> Using 2.6.0-alpha-2: 712 tests completed, 52 failed
> Using 2.6.0-alpha-3: fails with
>
>>  Could not find groovy-all.jar (org.codehaus.groovy:groovy-al
>> l:2.6.0-alpha-3).
>>   Searched in the following locations:
>>   https://jcenter.bintray.com/org/codehaus/groovy/groovy-all/
>> 2.6.0-alpha-3/groovy-all-2.6.0-alpha-3.jar
>>
>
> did not try 3.0.0-alpha-1, because it is from Nov. last year and did not
> have a change I suspect
>
> GriffonFXCollectionsExtensionTest seems to have worked for 2.5 and 2.6
> though
>
> Has anyone experimented a similar error? Any hints would be greatly
>> appreciated :-)
>>
>
> I think when I tried fixing Stream.of... which is a very similar case,
> since this is a static method on an interface as well. So I know that
> e34823cbabbce2a90829ead5d83c72806326946d and similar did cause some
> trouble and I do know there have been fixes. But I think they got applied
> to all branches. Can it be we forgot to backport something that got applied
> to 2.5 and 2.6 (and most likely master), but not 2.4? the class itself is
> the same in master and in 2.4.14 and on GROOVY_2_6_X... GROOVY_2_5_X seems
> to be missing the change?!
>
> For me this sounds like a "too many branches exception"
>
> bye Jochen
>
>


Re: Unexpected compilation error with 2.4.14

2018-03-06 Thread Paul King
Looks weird. We should never get a VerifyError, so worth raising a bug.
That line by itself seems to work okay in a script.
I won't get time until tomorrow to replicate properly. Someone else might
jump in in the meantime.

Cheers, Paul.

On Tue, Mar 6, 2018 at 10:23 PM, Andres Almiray  wrote:

> Hello everyone,
>
> I'm in the process of updating the Griffon build to use Groovy 2.4.14 and
> encountered a weird problem in one of the tests
> https://github.com/griffon/griffon/blob/development/
> subprojects/griffon-javafx-groovy/src/test/groovy/griffon/javafx/
> GriffonFXCollectionsExtensionTest.groovy#L78
>
> The test runs fine with 2.413 but generates the following stacktrace with
> 2.4.14
>
> java.lang.VerifyError: (class: java_util_function_Function$identity, method: 
> callStatic signature: 
> (Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;) Illegal type in 
> constant pool
>   at java.lang.Class.getDeclaredConstructors0(Native Method)
>   at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
>   at java.lang.Class.getConstructor0(Class.java:3075)
>   at java.lang.Class.getConstructor(Class.java:1825)
>   at 
> org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts.defineClassAndGetConstructor(ClassLoaderForClassArtifacts.java:82)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compileStaticMethod(CallSiteGenerator.java:262)
>   at 
> org.codehaus.groovy.reflection.CachedMethod.createStaticMetaMethodSite(CachedMethod.java:295)
>   at 
> org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.createStaticMetaMethodSite(StaticMetaMethodSite.java:114)
>   at groovy.lang.MetaClassImpl.createStaticSite(MetaClassImpl.java:3421)
>   at 
> groovy.lang.ExpandoMetaClass.createStaticSite(ExpandoMetaClass.java:1308)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallStaticSite(CallSiteArray.java:76)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:161)
>   at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
>   at 
> griffon.javafx.GriffonFXCollectionsExtensionTest.testOperationsWithObservable(GriffonFXCollectionsExtensionTest.groovy:78)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:116)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:59)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:39)
>   at 
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

Re: [ANNOUNCE] Apache Groovy 2.6.0-alpha-3 released

2018-03-05 Thread Paul King
Nice work Daniel!

On Tue, Mar 6, 2018 at 1:19 PM, 孙 岚  wrote:

> Dear community,
>
> The Apache Groovy team is pleased to announce version 2.6.0-alpha-3 of
> Apache Groovy.
> Apache Groovy is a multi-facet 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=12342190
>
> 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
> Jars are also available within the major binary repositories.
> We would like to thank all people who contributed to this release.
>
> We welcome your help and feedback. 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] Groovy 2.4.14 Windows Installer Released

2018-03-04 Thread Paul King
Thanks Keegan!

On Sun, Mar 4, 2018 at 3:26 PM, Keegan Witt  wrote:

> The Windows installer for Groovy 2.4.14 is available from the usual place:
> https://bintray.com/groovy/Distributions/download_file?
> file_path=groovy-2.4.14-installer.exe
>
> -Keegan
>


[ANNOUNCE] Apache Groovy 2.4.14 released

2018-03-01 Thread Paul King
Dear community,

The Apache Groovy team is pleased to announce version 2.4.14 of Apache Groovy.
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

This release is a maintenance release of the GROOVY_2_4_X branch.
It is strongly encouraged that all users using prior
versions on this branch upgrade to this version.

This release includes 13 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12342217

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
Jars are also available within the major binary repositories.
We would like to thank all people who contributed to this release.

We welcome your help and feedback. 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: Groovy Champions proposal feedback

2018-02-26 Thread 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 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 

[ANNOUNCE] Apache Groovy 2.5.0-beta-3 released

2018-02-23 Thread Paul King
[Apologies for the duplicate email - the previous one was missing the
subject line]

Dear community,

The Apache Groovy team is pleased to announce version 2.5.0-beta-3 of
Apache Groovy.
Apache Groovy is a multi-facet 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.
There are still a few things we plan to work on before the final release but
we anticipate this will be the last beta for the 2.5.0 release train.
So we'd greatly
appreciate as much testing as possible before we get the first RC ready shortly.

This release includes 39 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12341721

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
Jars are also available within the major binary repositories.
We would like to thank all people who contributed to this release.

We welcome your help and feedback. 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.


  1   2   3   >