[jira] [Resolved] (GROOVY-8807) Bump gradle to 4.10.2
[ https://issues.apache.org/jira/browse/GROOVY-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-8807. Resolution: Fixed Fixed by https://github.com/apache/groovy/commit/be7d6aa4ed63a6eebdebc0c32adf2a2f6eb129c5 > Bump gradle to 4.10.2 > - > > Key: GROOVY-8807 > URL: https://issues.apache.org/jira/browse/GROOVY-8807 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-4, 2.5.3 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8807) Bump gradle to 4.10.2
[ https://issues.apache.org/jira/browse/GROOVY-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-8807: --- Issue Type: Dependency upgrade (was: New Feature) > Bump gradle to 4.10.2 > - > > Key: GROOVY-8807 > URL: https://issues.apache.org/jira/browse/GROOVY-8807 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-4, 2.5.3 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8807) Bump gradle to 4.10.2
Daniel Sun created GROOVY-8807: -- Summary: Bump gradle to 4.10.2 Key: GROOVY-8807 URL: https://issues.apache.org/jira/browse/GROOVY-8807 Project: Groovy Issue Type: New Feature Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 3.0.0-alpha-4, 2.5.3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8794) Add groovy-yaml subproject to support parsing and building yaml
[ https://issues.apache.org/jira/browse/GROOVY-8794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun updated GROOVY-8794: --- Fix Version/s: (was: 2.5.3) 3.0.0-alpha-4 > Add groovy-yaml subproject to support parsing and building yaml > --- > > Key: GROOVY-8794 > URL: https://issues.apache.org/jira/browse/GROOVY-8794 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8794) Add groovy-yaml subproject to support parsing and building yaml
[ https://issues.apache.org/jira/browse/GROOVY-8794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-8794. Resolution: Fixed Fixed by https://github.com/apache/groovy/commit/16b24b8c4044b7aff2bc1451ffb76cfe94baff81 > Add groovy-yaml subproject to support parsing and building yaml > --- > > Key: GROOVY-8794 > URL: https://issues.apache.org/jira/browse/GROOVY-8794 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8794) Add groovy-yaml subproject to support parsing and building yaml
[ https://issues.apache.org/jira/browse/GROOVY-8794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16624172#comment-16624172 ] ASF GitHub Bot commented on GROOVY-8794: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/797 > Add groovy-yaml subproject to support parsing and building yaml > --- > > Key: GROOVY-8794 > URL: https://issues.apache.org/jira/browse/GROOVY-8794 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 2.5.3 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #797: GROOVY-8794: Add groovy-yaml subproject to support...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/797 ---
[jira] [Commented] (GROOVY-8805) GroovyScriptEngine reload fails when dependent class is deleted
[
https://issues.apache.org/jira/browse/GROOVY-8805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16624096#comment-16624096
]
ASF GitHub Bot commented on GROOVY-8805:
GitHub user gclayburg opened a pull request:
https://github.com/apache/groovy/pull/799
GROOVY-8805 reloading a script under GroovyScriptEngine should succee…
…d when dependent class is deleted
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gclayburg/groovy GROOVY_2_5_X
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/groovy/pull/799.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #799
commit b56ba11d335f969682b151719f5ad278bb695d9c
Author: Gary Clayburg
Date: 2018-09-21T19:50:23Z
GROOVY-8805 reloading a script under GroovyScriptEngine should succeed when
dependent class is deleted
> GroovyScriptEngine reload fails when dependent class is deleted
> ---
>
> Key: GROOVY-8805
> URL: https://issues.apache.org/jira/browse/GROOVY-8805
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Gary Clayburg
>Priority: Major
>
> When using GroovyScriptEngine.loadScriptByName(scriptName), the reloading
> will fail with a groovy.util.ResourceException if a dependent class has been
> removed from the script root filesystem. To reproduce this issue, start with
> a script and a dependent class:
> ClassA.groovy
> {code:java}
> DependentClass ic = new DependentClass(){code}
>
> DependentClass.groovy
>
> {code:java}
> class DependentClass {}
>
> {code}
>
> When these classes are initially compiled with GroovyScriptEngine, things
> work fine. There are no errors when loading the script like this:
>
> {code:java}
> gse.loadScriptByName('ClassA.groovy'){code}
>
> However, once DependentClass.groovy is completely removed from the filesystem
> and ClassA is modified to remove the reference, the same
> gse.loadScriptByName('ClassA.groovy') will fail with a
> groovy.utilResourceExeption.
>
> It appears GroovyScriptEngine keeps a dependency cache and gets confused in
> this case. The line that fails is a check for lastModifedTime of this
> dependency. The dependency of course no longer exists, but the check for
> lastModiedTime occurs before ClassA compile has been attempted.
>
> I am working on a PR that fixes this. It seems to me that inside
> gse.isSourceNewer(entry), it can just treat a ResourceException during
> getLastModifed(scriptName) as an indication to just attempt a recompile
> instead of throwing the exception.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] groovy pull request #799: GROOVY-8805 reloading a script under GroovyScriptE...
GitHub user gclayburg opened a pull request: https://github.com/apache/groovy/pull/799 GROOVY-8805 reloading a script under GroovyScriptEngine should succee⦠â¦d when dependent class is deleted You can merge this pull request into a Git repository by running: $ git pull https://github.com/gclayburg/groovy GROOVY_2_5_X Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/799.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #799 commit b56ba11d335f969682b151719f5ad278bb695d9c Author: Gary Clayburg Date: 2018-09-21T19:50:23Z GROOVY-8805 reloading a script under GroovyScriptEngine should succeed when dependent class is deleted ---
[jira] [Created] (GROOVY-8806) Immutable classes break in groovy 2.5.2
Roberto Perez Alcolea created GROOVY-8806:
-
Summary: Immutable classes break in groovy 2.5.2
Key: GROOVY-8806
URL: https://issues.apache.org/jira/browse/GROOVY-8806
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.2
Reporter: Roberto Perez Alcolea
We've being running tests of gradle plugins with latest gradle nightly release
which upgraded to groovy 2.5.2
Since then, we've seen multiple plugins breaking with errors around
immutability:
{code:java}
> Unsupported type (org.ajoberstar.grgit.Branch) found for field
> 'trackingBranch' while constructing immutable class
> org.ajoberstar.grgit.Branch.
Immutable classes only support properties with effectively immutable types
including:
- Strings, primitive types, wrapper types, Class, BigInteger and BigDecimal,
enums
- classes annotated with @KnownImmutable and known immutables (java.awt.Color,
java.net.URI)
- Cloneable classes, collections, maps and arrays, and other classes with
special handling
(java.util.Date and various java.time.* classes and interfaces)
Other restrictions apply, please see the groovydoc for ImmutableOptions for
further details{code}
I was wondering if this change is related to
[https://github.com/apache/groovy/commit/3471f55ea5839ab3c9dfa51cdca081bc7b4c020e#diff-8f745c460bc1abf332f21067b21ec551R754]
And also, looks like gradle plugins that use the gradleApi and are compiled
with groovy 2.4 could break with groovy 2.5 with usages like this one
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8805) GroovyScriptEngine reload fails when dependent class is deleted
Gary Clayburg created GROOVY-8805:
-
Summary: GroovyScriptEngine reload fails when dependent class is
deleted
Key: GROOVY-8805
URL: https://issues.apache.org/jira/browse/GROOVY-8805
Project: Groovy
Issue Type: Bug
Components: GroovyScriptEngine
Affects Versions: 2.5.2, 2.4.15
Reporter: Gary Clayburg
When using GroovyScriptEngine.loadScriptByName(scriptName), the reloading will
fail with a groovy.util.ResourceException if a dependent class has been removed
from the script root filesystem. To reproduce this issue, start with a script
and a dependent class:
ClassA.groovy
{code:java}
DependentClass ic = new DependentClass(){code}
DependentClass.groovy
{code:java}
class DependentClass {}
{code}
When these classes are initially compiled with GroovyScriptEngine, things work
fine. There are no errors when loading the script like this:
{code:java}
gse.loadScriptByName('ClassA.groovy'){code}
However, once DependentClass.groovy is completely removed from the filesystem
and ClassA is modified to remove the reference, the same
gse.loadScriptByName('ClassA.groovy') will fail with a
groovy.utilResourceExeption.
It appears GroovyScriptEngine keeps a dependency cache and gets confused in
this case. The line that fails is a check for lastModifedTime of this
dependency. The dependency of course no longer exists, but the check for
lastModiedTime occurs before ClassA compile has been attempted.
I am working on a PR that fixes this. It seems to me that inside
gse.isSourceNewer(entry), it can just treat a ResourceException during
getLastModifed(scriptName) as an indication to just attempt a recompile instead
of throwing the exception.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7165) Static Compilation: private static field accessed from a Closure produces a runtime error
[
https://issues.apache.org/jira/browse/GROOVY-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623745#comment-16623745
]
Eric Milles commented on GROOVY-7165:
-
Any chance of getting this fixed for 2.4.x and 2.5.3? Whether or not private
field access should be allowed is a topic for 3+. As indicated, private field
access does work in many cases. And so I would expect that moving from
"Type.VALUE" to "import static Type.VALUE" paired with "VALUE" should work as
well.
> Static Compilation: private static field accessed from a Closure produces a
> runtime error
> -
>
> Key: GROOVY-7165
> URL: https://issues.apache.org/jira/browse/GROOVY-7165
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.3.7
>Reporter: Neil Galarneau
>Priority: Major
>
> The following code compiles cleanly but throws an exception at runtime.
> This code doesn't have a stack trace. The code I simplified this from, did
> have a stack trace.
> If I remove 'private' from staticfield, then it works:
> {code}
> @CompileStatic
> class TestPrivateStaticFieldInClosure extends BaseBug
> {
> public static void main(String[] args)
> {
> (new TestPrivateStaticFieldInClosure()).show()
> }
> }
> @CompileStatic
> class BaseBug
> {
> private static ArrayList staticfield = new ArrayList<>()
> void show()
> {
> List, String>> runners = new ArrayList<>()
> runners.add(new Called())
> List cmds = ["hello"]
> runners.each { cmds.addAll(it.apply(staticfield)) }
> println cmds.size()
> }
> class Called implements Function, String>
> {
> @Override
> String apply(List strings) {
> "groovin"
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8327) Parser regression. Can't access static instance method before class is constructed
[
https://issues.apache.org/jira/browse/GROOVY-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isaac Dooley updated GROOVY-8327:
-
Description:
The parser in 2.5, 2.6, 3.0 gives a MultipleCompilationErrorsException on code
that compiled successfully in 2.4
{code:java|title=Code that fails to compile on 2.6.0-alpha-1}
class A {
static String g() { }
A() {
this({g()}) // It is ok to create a closure that calls g() in a
constructor, but not if it is being passed into this().
}
A(a) { }
}
{code}
{code:java|title=compilation error message}
$ groovyc test.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
test.groovy: 4: Can't access instance method 'g' before the class is constructed
@ line 4, column 15.
this({g()}) // It is ok to create a closure that calls g() in a
constructor, but not if it is being passed into this().
^
1 error
{code}
My opinion is that groovy should allow users to call a static method inside a
constructor before the instance has been fully constructed, but I'm not aware
of the details of why this is disallowed in 2.6.0-alpha-1.
was:
The parser in 2.6.0-alpha-1 gives a MultipleCompilationErrorsException on code
that compiled successfully in 2.4.12.
{code:title=Code that fails to compile on 2.6.0-alpha-1}
class A {
static String g() { }
A() {
this({g()}) // It is ok to create a closure that calls g() in a
constructor, but not if it is being passed into this().
}
A(a) { }
}
{code}
{code:title=compilation error message}
$ groovyc test.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
test.groovy: 4: Can't access instance method 'g' before the class is constructed
@ line 4, column 15.
this({g()}) // It is ok to create a closure that calls g() in a
constructor, but not if it is being passed into this().
^
1 error
{code}
My opinion is that groovy should allow users to call a static method inside a
constructor before the instance has been fully constructed, but I'm not aware
of the details of why this is disallowed in 2.6.0-alpha-1.
> Parser regression. Can't access static instance method before class is
> constructed
> --
>
> Key: GROOVY-8327
> URL: https://issues.apache.org/jira/browse/GROOVY-8327
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.6.0-alpha-1, 3.0.0-alpha-3, 2.5.2
> Environment: groovc command line on linux
>Reporter: Isaac Dooley
>Priority: Major
>
> The parser in 2.5, 2.6, 3.0 gives a MultipleCompilationErrorsException on
> code that compiled successfully in 2.4
> {code:java|title=Code that fails to compile on 2.6.0-alpha-1}
> class A {
> static String g() { }
> A() {
> this({g()}) // It is ok to create a closure that calls g() in a
> constructor, but not if it is being passed into this().
> }
> A(a) { }
> }
> {code}
> {code:java|title=compilation error message}
> $ groovyc test.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> test.groovy: 4: Can't access instance method 'g' before the class is
> constructed
> @ line 4, column 15.
>this({g()}) // It is ok to create a closure that calls g() in a
> constructor, but not if it is being passed into this().
> ^
> 1 error
> {code}
> My opinion is that groovy should allow users to call a static method inside a
> constructor before the instance has been fully constructed, but I'm not aware
> of the details of why this is disallowed in 2.6.0-alpha-1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8327) Parser regression. Can't access static instance method before class is constructed
[
https://issues.apache.org/jira/browse/GROOVY-8327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isaac Dooley updated GROOVY-8327:
-
Affects Version/s: 3.0.0-alpha-3
> Parser regression. Can't access static instance method before class is
> constructed
> --
>
> Key: GROOVY-8327
> URL: https://issues.apache.org/jira/browse/GROOVY-8327
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.6.0-alpha-1, 3.0.0-alpha-3, 2.5.2
> Environment: groovc command line on linux
>Reporter: Isaac Dooley
>Priority: Major
>
> The parser in 2.6.0-alpha-1 gives a MultipleCompilationErrorsException on
> code that compiled successfully in 2.4.12.
> {code:title=Code that fails to compile on 2.6.0-alpha-1}
> class A {
> static String g() { }
> A() {
> this({g()}) // It is ok to create a closure that calls g() in a
> constructor, but not if it is being passed into this().
> }
> A(a) { }
> }
> {code}
> {code:title=compilation error message}
> $ groovyc test.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> test.groovy: 4: Can't access instance method 'g' before the class is
> constructed
> @ line 4, column 15.
>this({g()}) // It is ok to create a closure that calls g() in a
> constructor, but not if it is being passed into this().
> ^
> 1 error
> {code}
> My opinion is that groovy should allow users to call a static method inside a
> constructor before the instance has been fully constructed, but I'm not aware
> of the details of why this is disallowed in 2.6.0-alpha-1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8753) Compiler error in STC: exception in phase 'instruction selection'
[
https://issues.apache.org/jira/browse/GROOVY-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623495#comment-16623495
]
Graeme Rocher commented on GROOVY-8753:
---
Note this issue also blocks upgrading Micronaut to 2.5.2
> Compiler error in STC: exception in phase 'instruction selection'
> -
>
> Key: GROOVY-8753
> URL: https://issues.apache.org/jira/browse/GROOVY-8753
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.5.2
> Environment: Java 8u181, Ubuntu 18.04
>Reporter: Patric Bechtel
>Assignee: Paul King
>Priority: Critical
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> Following source compiles under 2.5.1 and 3.0alpha3, but not 2.5.2:
> {code:java}
> @groovy.transform.CompileStatic
> class A {
> private List fooNames = []
> public A(Collection names) {
> names.each { fooNames << it }
> }
> public List getFooNames() { fooNames }
> }
> {code}
> error message is:
> {noformat}
> >>> a serious error occurred: BUG! exception in phase 'instruction selection'
> >>> in source unit 'A.groovy' Tried to overwrite existing meta data
> >>> org.codehaus.groovy.ast.expr.PropertyExpression@d9f41[object:
> >>> org.codehaus.groovy.ast.expr.VariableExpression@d9f41[variable: this]
> >>> property: ConstantExpression[fooNames]].
> >>> stacktrace:
> BUG! exception in phase 'instruction selection' in source unit 'A.groovy'
> Tried to overwrite existing meta data
> org.codehaus.groovy.ast.expr.PropertyExpression@d9f41[object:
> org.codehaus.groovy.ast.expr.VariableExpression@d9f41[variable: this]
> property: ConstantExpression[fooNames]].
> at org.codehaus.groovy.ast.ASTNode.setNodeMetaData(ASTNode.java:154)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.checkOrMarkPrivateAccess(StaticTypeCheckingVisitor.java:501)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.storeField(StaticTypeCheckingVisitor.java:1711)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.existsProperty(StaticTypeCheckingVisitor.java:1473)
> at
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.existsProperty(StaticCompilationVisitor.java:522)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.existsProperty(StaticTypeCheckingVisitor.java:1381)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitPropertyExpressionSilent(StaticTypeCheckingVisitor.java:726)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.tryVariableExpressionAsProperty(StaticTypeCheckingVisitor.java:711)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitVariableExpression(StaticTypeCheckingVisitor.java:630)
> at
> org.codehaus.groovy.ast.expr.VariableExpression.visit(VariableExpression.java:72)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBinaryExpression(StaticTypeCheckingVisitor.java:785)
> at
> org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:51)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:122)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:197)
> at
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:88)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:106)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBlockStatement(StaticTypeCheckingVisitor.java:3628)
> at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitClosureExpression(CodeVisitorSupport.java:227)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClosureExpression(StaticTypeCheckingVisitor.java:2286)
> at
> org.codehaus.groovy.ast.expr.ClosureExpression.visit(ClosureExpression.java:49)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallArguments(StaticTypeCheckingVisitor.java:2596)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:3286)
> at
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:397)
> at
> org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:70)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:122)
> at
>
