[GitHub] [groovy] paulk-asert removed a comment on issue #1054: upgrade ASM from 6.1.1 to 7.2 to fix https://issues.apache.org/jira/browse/GROOVY-9271
paulk-asert removed a comment on issue #1054: upgrade ASM from 6.1.1 to 7.2 to fix https://issues.apache.org/jira/browse/GROOVY-9271 URL: https://github.com/apache/groovy/pull/1054#issuecomment-579124372 You can close this. The Groovy 2.5 branch is already using 7.2. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [groovy] paulk-asert commented on issue #1054: upgrade ASM from 6.1.1 to 7.2 to fix https://issues.apache.org/jira/browse/GROOVY-9271
paulk-asert commented on issue #1054: upgrade ASM from 6.1.1 to 7.2 to fix https://issues.apache.org/jira/browse/GROOVY-9271 URL: https://github.com/apache/groovy/pull/1054#issuecomment-579124372 You can close this. The Groovy 2.5 branch is already using 7.2. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024778#comment-17024778
]
Paul King edited comment on GROOVY-9376 at 1/28/20 12:14 AM:
-
Your script seems to work for me (outside docker) using Groovy 2.5.0 and
3.0.0-rc-3.
In my case, it finds the jar from jcenter before even needing to try
maven.restlet.org.
It doesn't ignore the latter though since it tries to find the javadoc jar
which doesn't exist in any of the repos.
{noformat}
...
jcenter: found md file for org.restlet#org.restlet;1.1.6
=>
https://jcenter.bintray.com/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6.pom
(1.1.6)
...
trying
http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
tried
http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
HTTP response status: 404
url=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
CLIENT ERROR: Not Found
url=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
restlet.org: resource not reachable for org/restlet#org.restlet;1.1.6:
res=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
no javadoc artifact found for org.restlet#org.restlet;1.1.6
...
sha1 OK for
https://jcenter.bintray.com/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6.jar
[SUCCESSFUL ] org.restlet#org.restlet;1.1.6!org.restlet.jar (3223ms)
resolve done (6318ms resolve - 3233ms download)
{noformat}
As to whether we should be trying by default to download the javadoc jars, that
is a good question ... but another issue.
As to why maven.restlet.org doesn't appear in your log, I have no idea. We'll
have to dig deeper.
was (Author: paulk):
Your script seems to work for me using Groovy 2.5.0 and 3.0.0-rc-3.
In my case, it finds the jar from jcenter before even needing to try
maven.restlet.org.
It doesn't ignore the latter though since it tries to find the javadoc jar
which doesn't exist in any of the repos.
{noformat}
...
jcenter: found md file for org.restlet#org.restlet;1.1.6
=>
https://jcenter.bintray.com/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6.pom
(1.1.6)
...
trying
http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
tried
http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
HTTP response status: 404
url=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
CLIENT ERROR: Not Found
url=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
restlet.org: resource not reachable for org/restlet#org.restlet;1.1.6:
res=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
no javadoc artifact found for org.restlet#org.restlet;1.1.6
...
sha1 OK for
https://jcenter.bintray.com/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6.jar
[SUCCESSFUL ] org.restlet#org.restlet;1.1.6!org.restlet.jar (3223ms)
resolve done (6318ms resolve - 3233ms download)
{noformat}
As to whether we should be trying by default to download the javadoc jars, that
is a good question ... but another issue.
As to why maven.restlet.org doesn't appear in your log, I have no idea. We'll
have to dig deeper.
> Groovy completely ignores @GrabResolver annotation
> --
>
> Key: GROOVY-9376
> URL: https://issues.apache.org/jira/browse/GROOVY-9376
> Project: Groovy
> Issue Type: Bug
>Reporter: Damian Szuberski
>Priority: Major
>
> Steps to reproduce inside docker. Repository added using GrabResolver is
> completely ignored during resolution and fetching.
>
> Manually putting repository location into ~/.groovy/grapeConfig.xml solves
> the problem and make the custom repository work properly. Tested on Groovy
> 2.5.x and Groovy 3.x, both have the same issue. This example comes from
> docker container *groovy:3.0.0-rc-3-jre8*
>
> *root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
> *root@40bc8b504667:~# cat example.groovy*
> {code:java}
> #!/usr/bin/env groovy
> @GrabResolver(name='restlet.org', root='http://maven.restlet.org')
> @Grab(group='org.restlet', module='org.restlet', version='1.1.6')
> import org.restlet.Restlet;
> {code}
> *root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
> -Divy.message.logger.level=4 example.groovy*
> {noformat}
> setting 'ivy.default.settings.dir' to
> 'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
> setting 'ivy.basedir' to '/root/.'
> setting 'ivy.default.conf.dir' to
> 'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
> setting
[jira] [Commented] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024778#comment-17024778
]
Paul King commented on GROOVY-9376:
---
Your script seems to work for me using Groovy 2.5.0 and 3.0.0-rc-3.
In my case, it finds the jar from jcenter before even needing to try
maven.restlet.org.
It doesn't ignore the latter though since it tries to find the javadoc jar
which doesn't exist in any of the repos.
{noformat}
...
jcenter: found md file for org.restlet#org.restlet;1.1.6
=>
https://jcenter.bintray.com/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6.pom
(1.1.6)
...
trying
http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
tried
http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
HTTP response status: 404
url=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
CLIENT ERROR: Not Found
url=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
restlet.org: resource not reachable for org/restlet#org.restlet;1.1.6:
res=http://maven.restlet.org/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6-javadoc.jar
no javadoc artifact found for org.restlet#org.restlet;1.1.6
...
sha1 OK for
https://jcenter.bintray.com/org/restlet/org.restlet/1.1.6/org.restlet-1.1.6.jar
[SUCCESSFUL ] org.restlet#org.restlet;1.1.6!org.restlet.jar (3223ms)
resolve done (6318ms resolve - 3233ms download)
{noformat}
As to whether we should be trying by default to download the javadoc jars, that
is a good question ... but another issue.
As to why maven.restlet.org doesn't appear in your log, I have no idea. We'll
have to dig deeper.
> Groovy completely ignores @GrabResolver annotation
> --
>
> Key: GROOVY-9376
> URL: https://issues.apache.org/jira/browse/GROOVY-9376
> Project: Groovy
> Issue Type: Bug
>Reporter: Damian Szuberski
>Priority: Major
>
> Steps to reproduce inside docker. Repository added using GrabResolver is
> completely ignored during resolution and fetching.
>
> Manually putting repository location into ~/.groovy/grapeConfig.xml solves
> the problem and make the custom repository work properly. Tested on Groovy
> 2.5.x and Groovy 3.x, both have the same issue. This example comes from
> docker container *groovy:3.0.0-rc-3-jre8*
>
> *root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
> *root@40bc8b504667:~# cat example.groovy*
> {code:java}
> #!/usr/bin/env groovy
> @GrabResolver(name='restlet.org', root='http://maven.restlet.org')
> @Grab(group='org.restlet', module='org.restlet', version='1.1.6')
> import org.restlet.Restlet;
> {code}
> *root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
> -Divy.message.logger.level=4 example.groovy*
> {noformat}
> setting 'ivy.default.settings.dir' to
> 'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
> setting 'ivy.basedir' to '/root/.'
> setting 'ivy.default.conf.dir' to
> 'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
> setting 'java.runtime.name' to 'OpenJDK Runtime Environment'
> setting 'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'
> setting 'java.vm.version' to '25.232-b09'
> setting 'groovy.grape.report.downloads' to 'true'
> setting 'java.vm.vendor' to 'AdoptOpenJDK'
> setting 'java.vendor.url' to 'http://java.oracle.com/'
> setting 'path.separator' to ':'
> setting 'java.vm.name' to 'OpenJDK 64-Bit Server VM'
> setting 'file.encoding.pkg' to 'sun.io'
> setting 'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'
> setting 'sun.os.patch.level' to 'unknown'
> setting 'program.name' to 'groovy'
> setting 'java.vm.specification.name' to 'Java Virtual Machine Specification'
> setting 'user.dir' to '/root'
> setting 'java.runtime.version' to '1.8.0_232-b09'
> setting 'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'
> setting 'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'
> setting 'os.arch' to 'amd64'
> setting 'java.io.tmpdir' to '/tmp'
> setting 'line.separator' to ''
> setting 'java.vm.specification.vendor' to 'Oracle Corporation'
> setting 'os.name' to 'Linux'
> setting 'tools.jar' to '/opt/java/openjdk/lib/tools.jar'
> setting 'sun.jnu.encoding' to 'UTF-8'
> setting 'script.name' to '/usr/bin/groovy'
> setting 'java.library.path' to
> '/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'
> setting 'java.specification.name' to 'Java Platform API Specification'
> setting 'java.class.version' to '52.0'
> setting 'sun.management.compiler' to 'HotSpot 64-Bit Tiered Compilers'
> setting 'os.version' to '5.4.0-3-amd64'
> setting 'user.home' to '/root'
> setting 'user.timezone' to ''
> setting 'java.awt.printerjob' to
[jira] [Updated] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9376:
--
Description:
Steps to reproduce inside docker. Repository added using GrabResolver is
completely ignored during resolution and fetching.
Manually putting repository location into ~/.groovy/grapeConfig.xml solves the
problem and make the custom repository work properly. Tested on Groovy 2.5.x
and Groovy 3.x, both have the same issue. This example comes from docker
container *groovy:3.0.0-rc-3-jre8*
*root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
*root@40bc8b504667:~# cat example.groovy*
{code:java}
#!/usr/bin/env groovy
@GrabResolver(name='restlet.org', root='http://maven.restlet.org')
@Grab(group='org.restlet', module='org.restlet', version='1.1.6')
import org.restlet.Restlet;
{code}
*root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
-Divy.message.logger.level=4 example.groovy*
{noformat}
setting 'ivy.default.settings.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
setting 'ivy.basedir' to '/root/.'
setting 'ivy.default.conf.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
setting 'java.runtime.name' to 'OpenJDK Runtime Environment'
setting 'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'
setting 'java.vm.version' to '25.232-b09'
setting 'groovy.grape.report.downloads' to 'true'
setting 'java.vm.vendor' to 'AdoptOpenJDK'
setting 'java.vendor.url' to 'http://java.oracle.com/'
setting 'path.separator' to ':'
setting 'java.vm.name' to 'OpenJDK 64-Bit Server VM'
setting 'file.encoding.pkg' to 'sun.io'
setting 'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'
setting 'sun.os.patch.level' to 'unknown'
setting 'program.name' to 'groovy'
setting 'java.vm.specification.name' to 'Java Virtual Machine Specification'
setting 'user.dir' to '/root'
setting 'java.runtime.version' to '1.8.0_232-b09'
setting 'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'
setting 'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'
setting 'os.arch' to 'amd64'
setting 'java.io.tmpdir' to '/tmp'
setting 'line.separator' to ''
setting 'java.vm.specification.vendor' to 'Oracle Corporation'
setting 'os.name' to 'Linux'
setting 'tools.jar' to '/opt/java/openjdk/lib/tools.jar'
setting 'sun.jnu.encoding' to 'UTF-8'
setting 'script.name' to '/usr/bin/groovy'
setting 'java.library.path' to
'/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'
setting 'java.specification.name' to 'Java Platform API Specification'
setting 'java.class.version' to '52.0'
setting 'sun.management.compiler' to 'HotSpot 64-Bit Tiered Compilers'
setting 'os.version' to '5.4.0-3-amd64'
setting 'user.home' to '/root'
setting 'user.timezone' to ''
setting 'java.awt.printerjob' to 'sun.print.PSPrinterJob'
setting 'file.encoding' to 'UTF-8'
setting 'java.specification.version' to '1.8'
setting 'java.class.path' to '/opt/groovy/lib/groovy-3.0.0-rc-3.jar'
setting 'user.name' to 'root'
setting 'ivy.message.logger.level' to '4'
setting 'java.vm.specification.version' to '1.8'
setting 'sun.java.command' to 'org.codehaus.groovy.tools.GroovyStarter --main
groovy.ui.GroovyMain --conf /opt/groovy/conf/groovy-starter.conf --classpath .
-Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
example.groovy'
setting 'java.home' to '/opt/java/openjdk'
setting 'sun.arch.data.model' to '64'
setting 'user.language' to 'en'
setting 'java.specification.vendor' to 'Oracle Corporation'
setting 'awt.toolkit' to 'sun.awt.X11.XToolkit'
setting 'java.vm.info' to 'mixed mode'
setting 'java.version' to '1.8.0_232'
setting 'java.ext.dirs' to
'/opt/java/openjdk/lib/ext:/usr/java/packages/lib/ext'
setting 'sun.boot.class.path' to
'/opt/java/openjdk/lib/resources.jar:/opt/java/openjdk/lib/rt.jar:/opt/java/openjdk/lib/sunrsasign.jar:/opt/java/openjdk/lib/jsse.jar:/opt/java/openjdk/lib/jce.jar:/opt/java/openjdk/lib/charsets.jar:/opt/java/openjdk/lib/jfr.jar:/opt/java/openjdk/classes'
setting 'java.vendor' to 'AdoptOpenJDK'
setting 'file.separator' to '/'
setting 'groovy.jaxb' to 'jaxb'
setting 'java.vendor.url.bug' to 'http://bugreport.sun.com/bugreport/'
setting 'sun.io.unicode.encoding' to 'UnicodeLittle'
setting 'sun.cpu.endian' to 'little'
setting 'groovy.starter.conf' to '/opt/groovy/conf/groovy-starter.conf'
setting 'groovy.home' to '/opt/groovy'
setting 'sun.cpu.isalist' to ''
setting 'user.home.url' to 'file:/root/':: loading settings :: url =
jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting]
'ivy.settings.url' to
'jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting]
'ivy.conf.url' to
[jira] [Updated] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9376:
--
Description:
Steps to reproduce inside docker. Repository added using GrabResolver is
completely ignored during resolution and fetching.
Manually putting repository location into ~/.groovy/grapeConfig.xml solves the
problem and make the custom repository work properly. Tested on Groovy 2.5.x
and Groovy 3.x, both have the same issue. This example comes from docker
container *groovy:3.0.0-rc-3-jre8*
*root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
*root@40bc8b504667:~# cat example.groovy*
{code:java}
#!/usr/bin/env groovy
@GrabResolver(name='restlet.org', root='http://maven.restlet.org')
@Grab(group='org.restlet', module='org.restlet', version='1.1.6')
import org.restlet.Restlet;
{code}
*root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
-Divy.message.logger.level=4 example.groovy*
{noformat}
setting 'ivy.default.settings.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
setting 'ivy.basedir' to '/root/.'
setting 'ivy.default.conf.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
setting 'java.runtime.name' to 'OpenJDK Runtime Environment'
setting 'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'
setting 'java.vm.version' to '25.232-b09'
setting 'groovy.grape.report.downloads' to 'true'
setting 'java.vm.vendor' to 'AdoptOpenJDK'
setting 'java.vendor.url' to 'http://java.oracle.com/'
setting 'path.separator' to ':'
setting 'java.vm.name' to 'OpenJDK 64-Bit Server VM'
setting 'file.encoding.pkg' to 'sun.io'
setting 'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'
setting 'sun.os.patch.level' to 'unknown'
setting 'program.name' to 'groovy'
setting 'java.vm.specification.name' to 'Java Virtual Machine Specification'
setting 'user.dir' to '/root'
setting 'java.runtime.version' to '1.8.0_232-b09'
setting 'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'
setting 'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'
setting 'os.arch' to 'amd64'
setting 'java.io.tmpdir' to '/tmp'
setting 'line.separator' to ''
setting 'java.vm.specification.vendor' to 'Oracle Corporation'
setting 'os.name' to 'Linux'
setting 'tools.jar' to '/opt/java/openjdk/lib/tools.jar'
setting 'sun.jnu.encoding' to 'UTF-8'
setting 'script.name' to '/usr/bin/groovy'
setting 'java.library.path' to
'/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'
setting 'java.specification.name' to 'Java Platform API Specification'
setting 'java.class.version' to '52.0'
setting 'sun.management.compiler' to 'HotSpot 64-Bit Tiered Compilers'
setting 'os.version' to '5.4.0-3-amd64'
setting 'user.home' to '/root'
setting 'user.timezone' to ''
setting 'java.awt.printerjob' to 'sun.print.PSPrinterJob'
setting 'file.encoding' to 'UTF-8'
setting 'java.specification.version' to '1.8'
setting 'java.class.path' to '/opt/groovy/lib/groovy-3.0.0-rc-3.jar'
setting 'user.name' to 'root'
setting 'ivy.message.logger.level' to '4'
setting 'java.vm.specification.version' to '1.8'
setting 'sun.java.command' to 'org.codehaus.groovy.tools.GroovyStarter --main
groovy.ui.GroovyMain --conf /opt/groovy/conf/groovy-starter.conf --classpath .
-Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
example.groovy'
setting 'java.home' to '/opt/java/openjdk'
setting 'sun.arch.data.model' to '64'
setting 'user.language' to 'en'
setting 'java.specification.vendor' to 'Oracle Corporation'
setting 'awt.toolkit' to 'sun.awt.X11.XToolkit'
setting 'java.vm.info' to 'mixed mode'
setting 'java.version' to '1.8.0_232'
setting 'java.ext.dirs' to
'/opt/java/openjdk/lib/ext:/usr/java/packages/lib/ext'
setting 'sun.boot.class.path' to
'/opt/java/openjdk/lib/resources.jar:/opt/java/openjdk/lib/rt.jar:/opt/java/openjdk/lib/sunrsasign.jar:/opt/java/openjdk/lib/jsse.jar:/opt/java/openjdk/lib/jce.jar:/opt/java/openjdk/lib/charsets.jar:/opt/java/openjdk/lib/jfr.jar:/opt/java/openjdk/classes'
setting 'java.vendor' to 'AdoptOpenJDK'
setting 'file.separator' to '/'
setting 'groovy.jaxb' to 'jaxb'
setting 'java.vendor.url.bug' to 'http://bugreport.sun.com/bugreport/'
setting 'sun.io.unicode.encoding' to 'UnicodeLittle'
setting 'sun.cpu.endian' to 'little'
setting 'groovy.starter.conf' to '/opt/groovy/conf/groovy-starter.conf'
setting 'groovy.home' to '/opt/groovy'
setting 'sun.cpu.isalist' to ''
setting 'user.home.url' to 'file:/root/':: loading settings :: url =
jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting]
'ivy.settings.url' to
'jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting]
'ivy.conf.url' to
[jira] [Updated] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9376:
--
Description:
Steps to reproduce inside docker. Repository added using GrabResolver is
completely ignored during resolution and fetching.
Manually putting repository location into ~/.groovy/grapeConfig.xml solves the
problem and make the custom repository work properly. Tested on Groovy 2.5.x
and Groovy 3.x, both have the same issue. This example comes from docker
container *groovy:3.0.0-rc-3-jre8*
*root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
*root@40bc8b504667:~# cat example.groovy*
{code:java}
#!/usr/bin/env groovy
@GrabResolver(name='restlet.org', root='http://maven.restlet.org')
@Grab(group='org.restlet', module='org.restlet', version='1.1.6')
import org.restlet.Restlet;
{code}
*root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
-Divy.message.logger.level=4 example.groovy*
{noformat}
setting 'ivy.default.settings.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
setting 'ivy.basedir' to '/root/.'
setting 'ivy.default.conf.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
setting 'java.runtime.name' to 'OpenJDK Runtime Environment'
setting 'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'
setting 'java.vm.version' to '25.232-b09'
setting 'groovy.grape.report.downloads' to 'true'
setting 'java.vm.vendor' to 'AdoptOpenJDK'
setting 'java.vendor.url' to 'http://java.oracle.com/'
setting 'path.separator' to ':'
setting 'java.vm.name' to 'OpenJDK 64-Bit Server VM'
setting 'file.encoding.pkg' to 'sun.io'
setting 'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'
setting 'sun.os.patch.level' to 'unknown'
setting 'program.name' to 'groovy'
setting 'java.vm.specification.name' to 'Java Virtual Machine Specification'
setting 'user.dir' to '/root'
setting 'java.runtime.version' to '1.8.0_232-b09'
setting 'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'
setting 'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'
setting 'os.arch' to 'amd64'
setting 'java.io.tmpdir' to '/tmp'
setting 'line.separator' to ''
setting 'java.vm.specification.vendor' to 'Oracle Corporation'
setting 'os.name' to 'Linux'
setting 'tools.jar' to '/opt/java/openjdk/lib/tools.jar'
setting 'sun.jnu.encoding' to 'UTF-8'
setting 'script.name' to '/usr/bin/groovy'
setting 'java.library.path' to
'/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'
setting 'java.specification.name' to 'Java Platform API Specification'
setting 'java.class.version' to '52.0'
setting 'sun.management.compiler' to 'HotSpot 64-Bit Tiered Compilers'
setting 'os.version' to '5.4.0-3-amd64'
setting 'user.home' to '/root'
setting 'user.timezone' to ''
setting 'java.awt.printerjob' to 'sun.print.PSPrinterJob'
setting 'file.encoding' to 'UTF-8'
setting 'java.specification.version' to '1.8'
setting 'java.class.path' to '/opt/groovy/lib/groovy-3.0.0-rc-3.jar'
setting 'user.name' to 'root'
setting 'ivy.message.logger.level' to '4'
setting 'java.vm.specification.version' to '1.8'
setting 'sun.java.command' to 'org.codehaus.groovy.tools.GroovyStarter --main
groovy.ui.GroovyMain --conf /opt/groovy/conf/groovy-starter.conf --classpath .
-Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
example.groovy'
setting 'java.home' to '/opt/java/openjdk'
setting 'sun.arch.data.model' to '64'
setting 'user.language' to 'en'
setting 'java.specification.vendor' to 'Oracle Corporation'
setting 'awt.toolkit' to 'sun.awt.X11.XToolkit'
setting 'java.vm.info' to 'mixed mode'
setting 'java.version' to '1.8.0_232'
setting 'java.ext.dirs' to
'/opt/java/openjdk/lib/ext:/usr/java/packages/lib/ext'
setting 'sun.boot.class.path' to
'/opt/java/openjdk/lib/resources.jar:/opt/java/openjdk/lib/rt.jar:/opt/java/openjdk/lib/sunrsasign.jar:/opt/java/openjdk/lib/jsse.jar:/opt/java/openjdk/lib/jce.jar:/opt/java/openjdk/lib/charsets.jar:/opt/java/openjdk/lib/jfr.jar:/opt/java/openjdk/classes'
setting 'java.vendor' to 'AdoptOpenJDK'
setting 'file.separator' to '/'
setting 'groovy.jaxb' to 'jaxb'
setting 'java.vendor.url.bug' to 'http://bugreport.sun.com/bugreport/'
setting 'sun.io.unicode.encoding' to 'UnicodeLittle'
setting 'sun.cpu.endian' to 'little'
setting 'groovy.starter.conf' to '/opt/groovy/conf/groovy-starter.conf'
setting 'groovy.home' to '/opt/groovy'
setting 'sun.cpu.isalist' to ''
setting 'user.home.url' to 'file:/root/':: loading settings :: url =
jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting]
'ivy.settings.url' to
'jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting]
'ivy.conf.url' to
[jira] [Updated] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9376:
--
Description:
Steps to reproduce inside docker. Repository added using GrabResolver is
completely ignored during resolution and fetching.
Manually putting repository location into ~/.groovy/grapeConfig.xml solves the
problem and make the custom repository work properly. Tested on Groovy 2.5.x
and Groovy 3.x, both have the same issue. This example comes from docker
container *groovy:3.0.0-rc-3-jre8*
*root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
*root@40bc8b504667:~# cat example.groovy*
{code:java}
#!/usr/bin/env groovy
@GrabResolver(name='restlet.org', root='http://maven.restlet.org')
@Grab(group='org.restlet', module='org.restlet', version='1.1.6')
import org.restlet.Restlet;
{code}
*root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
-Divy.message.logger.level=4 example.groovy*
{noformat}
setting 'ivy.default.settings.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
setting 'ivy.basedir' to '/root/.'
setting 'ivy.default.conf.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'
setting 'java.runtime.name' to 'OpenJDK Runtime Environment'
setting 'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'
setting 'java.vm.version' to '25.232-b09'
setting 'groovy.grape.report.downloads' to 'true'
setting 'java.vm.vendor' to 'AdoptOpenJDK'
setting 'java.vendor.url' to 'http://java.oracle.com/'
setting 'path.separator' to ':'
setting 'java.vm.name' to 'OpenJDK 64-Bit Server VM'
setting 'file.encoding.pkg' to 'sun.io'
setting 'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'
setting 'sun.os.patch.level' to 'unknown'
setting 'program.name' to 'groovy'
setting 'java.vm.specification.name' to 'Java Virtual Machine Specification'
setting 'user.dir' to '/root'
setting 'java.runtime.version' to '1.8.0_232-b09'
setting 'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'
setting 'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'
setting 'os.arch' to 'amd64'
setting 'java.io.tmpdir' to '/tmp'
setting 'line.separator' to ''setting 'java.vm.specification.vendor' to 'Oracle
Corporation'setting 'os.name' to 'Linux'setting 'tools.jar' to
'/opt/java/openjdk/lib/tools.jar'setting 'sun.jnu.encoding' to 'UTF-8'setting
'script.name' to '/usr/bin/groovy'setting 'java.library.path' to
'/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'setting
'java.specification.name' to 'Java Platform API Specification'setting
'java.class.version' to '52.0'setting 'sun.management.compiler' to 'HotSpot
64-Bit Tiered Compilers'setting 'os.version' to '5.4.0-3-amd64'setting
'user.home' to '/root'setting 'user.timezone' to ''setting
'java.awt.printerjob' to 'sun.print.PSPrinterJob'setting 'file.encoding' to
'UTF-8'setting 'java.specification.version' to '1.8'setting 'java.class.path'
to '/opt/groovy/lib/groovy-3.0.0-rc-3.jar'setting 'user.name' to 'root'setting
'ivy.message.logger.level' to '4'setting 'java.vm.specification.version' to
'1.8'setting 'sun.java.command' to 'org.codehaus.groovy.tools.GroovyStarter
--main groovy.ui.GroovyMain --conf /opt/groovy/conf/groovy-starter.conf
--classpath . -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
example.groovy'setting 'java.home' to '/opt/java/openjdk'setting
'sun.arch.data.model' to '64'setting 'user.language' to 'en'setting
'java.specification.vendor' to 'Oracle Corporation'setting 'awt.toolkit' to
'sun.awt.X11.XToolkit'setting 'java.vm.info' to 'mixed mode'setting
'java.version' to '1.8.0_232'setting 'java.ext.dirs' to
'/opt/java/openjdk/lib/ext:/usr/java/packages/lib/ext'setting
'sun.boot.class.path' to
'/opt/java/openjdk/lib/resources.jar:/opt/java/openjdk/lib/rt.jar:/opt/java/openjdk/lib/sunrsasign.jar:/opt/java/openjdk/lib/jsse.jar:/opt/java/openjdk/lib/jce.jar:/opt/java/openjdk/lib/charsets.jar:/opt/java/openjdk/lib/jfr.jar:/opt/java/openjdk/classes'setting
'java.vendor' to 'AdoptOpenJDK'setting 'file.separator' to '/'setting
'groovy.jaxb' to 'jaxb'setting 'java.vendor.url.bug' to
'http://bugreport.sun.com/bugreport/'setting 'sun.io.unicode.encoding' to
'UnicodeLittle'setting 'sun.cpu.endian' to 'little'setting
'groovy.starter.conf' to '/opt/groovy/conf/groovy-starter.conf'setting
'groovy.home' to '/opt/groovy'setting 'sun.cpu.isalist' to ''setting
'user.home.url' to 'file:/root/':: loading settings :: url =
jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting]
'ivy.settings.url' to
'jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting]
'ivy.conf.url' to
[jira] [Updated] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9376:
--
Description:
Steps to reproduce inside docker. Repository added using GrabResolver is
completely ignored during resolution and fetching.
Manually putting repository location into ~/.groovy/grapeConfig.xml solves the
problem and make the custom repository work properly. Tested on Groovy 2.5.x
and Groovy 3.x, both have the same issue. This example comes from docker
container *groovy:3.0.0-rc-3-jre8*
*root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
*root@40bc8b504667:~# cat example.groovy*
{code:java}
#!/usr/bin/env groovy
@GrabResolver(name='restlet.org', root='http://maven.restlet.org')
@Grab(group='org.restlet', module='org.restlet', version='1.1.6')
import org.restlet.Restlet;
{code}
*root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
-Divy.message.logger.level=4 example.groovy*
{noformat}
setting 'ivy.default.settings.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting|file://opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting]
'ivy.basedir' to '/root/.'setting 'ivy.default.conf.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting|file://opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting]
'java.runtime.name' to 'OpenJDK Runtime Environment'setting
'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'setting
'java.vm.version' to '25.232-b09'setting 'groovy.grape.report.downloads' to
'true'setting 'java.vm.vendor' to 'AdoptOpenJDK'setting 'java.vendor.url' to
'http://java.oracle.com/'setting 'path.separator' to ':'setting 'java.vm.name'
to 'OpenJDK 64-Bit Server VM'setting 'file.encoding.pkg' to 'sun.io'setting
'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'setting
'sun.os.patch.level' to 'unknown'setting 'program.name' to 'groovy'setting
'java.vm.specification.name' to 'Java Virtual Machine Specification'setting
'user.dir' to '/root'setting 'java.runtime.version' to '1.8.0_232-b09'setting
'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'setting
'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'setting 'os.arch' to
'amd64'setting 'java.io.tmpdir' to '/tmp'setting 'line.separator' to ''setting
'java.vm.specification.vendor' to 'Oracle Corporation'setting 'os.name' to
'Linux'setting 'tools.jar' to '/opt/java/openjdk/lib/tools.jar'setting
'sun.jnu.encoding' to 'UTF-8'setting 'script.name' to '/usr/bin/groovy'setting
'java.library.path' to
'/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'setting
'java.specification.name' to 'Java Platform API Specification'setting
'java.class.version' to '52.0'setting 'sun.management.compiler' to 'HotSpot
64-Bit Tiered Compilers'setting 'os.version' to '5.4.0-3-amd64'setting
'user.home' to '/root'setting 'user.timezone' to ''setting
'java.awt.printerjob' to 'sun.print.PSPrinterJob'setting 'file.encoding' to
'UTF-8'setting 'java.specification.version' to '1.8'setting 'java.class.path'
to '/opt/groovy/lib/groovy-3.0.0-rc-3.jar'setting 'user.name' to 'root'setting
'ivy.message.logger.level' to '4'setting 'java.vm.specification.version' to
'1.8'setting 'sun.java.command' to 'org.codehaus.groovy.tools.GroovyStarter
--main groovy.ui.GroovyMain --conf /opt/groovy/conf/groovy-starter.conf
--classpath . -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
example.groovy'setting 'java.home' to '/opt/java/openjdk'setting
'sun.arch.data.model' to '64'setting 'user.language' to 'en'setting
'java.specification.vendor' to 'Oracle Corporation'setting 'awt.toolkit' to
'sun.awt.X11.XToolkit'setting 'java.vm.info' to 'mixed mode'setting
'java.version' to '1.8.0_232'setting 'java.ext.dirs' to
'/opt/java/openjdk/lib/ext:/usr/java/packages/lib/ext'setting
'sun.boot.class.path' to
'/opt/java/openjdk/lib/resources.jar:/opt/java/openjdk/lib/rt.jar:/opt/java/openjdk/lib/sunrsasign.jar:/opt/java/openjdk/lib/jsse.jar:/opt/java/openjdk/lib/jce.jar:/opt/java/openjdk/lib/charsets.jar:/opt/java/openjdk/lib/jfr.jar:/opt/java/openjdk/classes'setting
'java.vendor' to 'AdoptOpenJDK'setting 'file.separator' to '/'setting
'groovy.jaxb' to 'jaxb'setting 'java.vendor.url.bug' to
'http://bugreport.sun.com/bugreport/'setting 'sun.io.unicode.encoding' to
'UnicodeLittle'setting 'sun.cpu.endian' to 'little'setting
'groovy.starter.conf' to '/opt/groovy/conf/groovy-starter.conf'setting
'groovy.home' to '/opt/groovy'setting 'sun.cpu.isalist' to ''setting
'user.home.url' to 'file:/root/':: loading settings :: url =
jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting]
'ivy.settings.url' to
[jira] [Updated] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9376:
--
Description:
Steps to reproduce inside docker. Repository added using GrabResolver is
completely ignored during resolution and fetching.
Manually putting repository location into ~/.groovy/grapeConfig.xml solves the
problem and make the custom repository work properly. Tested on Groovy 2.5.x
and Groovy 3.x, both have the same issue. This example comes from docker
container *groovy:3.0.0-rc-3-jre8*
*root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
*root@40bc8b504667:~# cat example.groovy*
{code:java}
#!/usr/bin/env groovy
@GrabResolver(name='restlet.org', root='http://maven.restlet.org')
@Grab(group='org.restlet', module='org.restlet', version='1.1.6')
import org.restlet.Restlet;
{code}
*root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
-Divy.message.logger.level=4 example.groovy*
setting 'ivy.default.settings.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting|file://opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting]
'ivy.basedir' to '/root/.'setting 'ivy.default.conf.dir' to
'jar:[file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting|file://opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting]
'java.runtime.name' to 'OpenJDK Runtime Environment'setting
'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'setting
'java.vm.version' to '25.232-b09'setting 'groovy.grape.report.downloads' to
'true'setting 'java.vm.vendor' to 'AdoptOpenJDK'setting 'java.vendor.url' to
'http://java.oracle.com/'setting 'path.separator' to ':'setting 'java.vm.name'
to 'OpenJDK 64-Bit Server VM'setting 'file.encoding.pkg' to 'sun.io'setting
'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'setting
'sun.os.patch.level' to 'unknown'setting 'program.name' to 'groovy'setting
'java.vm.specification.name' to 'Java Virtual Machine Specification'setting
'user.dir' to '/root'setting 'java.runtime.version' to '1.8.0_232-b09'setting
'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'setting
'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'setting 'os.arch' to
'amd64'setting 'java.io.tmpdir' to '/tmp'setting 'line.separator' to ''setting
'java.vm.specification.vendor' to 'Oracle Corporation'setting 'os.name' to
'Linux'setting 'tools.jar' to '/opt/java/openjdk/lib/tools.jar'setting
'sun.jnu.encoding' to 'UTF-8'setting 'script.name' to '/usr/bin/groovy'setting
'java.library.path' to
'/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'setting
'java.specification.name' to 'Java Platform API Specification'setting
'java.class.version' to '52.0'setting 'sun.management.compiler' to 'HotSpot
64-Bit Tiered Compilers'setting 'os.version' to '5.4.0-3-amd64'setting
'user.home' to '/root'setting 'user.timezone' to ''setting
'java.awt.printerjob' to 'sun.print.PSPrinterJob'setting 'file.encoding' to
'UTF-8'setting 'java.specification.version' to '1.8'setting 'java.class.path'
to '/opt/groovy/lib/groovy-3.0.0-rc-3.jar'setting 'user.name' to 'root'setting
'ivy.message.logger.level' to '4'setting 'java.vm.specification.version' to
'1.8'setting 'sun.java.command' to 'org.codehaus.groovy.tools.GroovyStarter
--main groovy.ui.GroovyMain --conf /opt/groovy/conf/groovy-starter.conf
--classpath . -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
example.groovy'setting 'java.home' to '/opt/java/openjdk'setting
'sun.arch.data.model' to '64'setting 'user.language' to 'en'setting
'java.specification.vendor' to 'Oracle Corporation'setting 'awt.toolkit' to
'sun.awt.X11.XToolkit'setting 'java.vm.info' to 'mixed mode'setting
'java.version' to '1.8.0_232'setting 'java.ext.dirs' to
'/opt/java/openjdk/lib/ext:/usr/java/packages/lib/ext'setting
'sun.boot.class.path' to
'/opt/java/openjdk/lib/resources.jar:/opt/java/openjdk/lib/rt.jar:/opt/java/openjdk/lib/sunrsasign.jar:/opt/java/openjdk/lib/jsse.jar:/opt/java/openjdk/lib/jce.jar:/opt/java/openjdk/lib/charsets.jar:/opt/java/openjdk/lib/jfr.jar:/opt/java/openjdk/classes'setting
'java.vendor' to 'AdoptOpenJDK'setting 'file.separator' to '/'setting
'groovy.jaxb' to 'jaxb'setting 'java.vendor.url.bug' to
'http://bugreport.sun.com/bugreport/'setting 'sun.io.unicode.encoding' to
'UnicodeLittle'setting 'sun.cpu.endian' to 'little'setting
'groovy.starter.conf' to '/opt/groovy/conf/groovy-starter.conf'setting
'groovy.home' to '/opt/groovy'setting 'sun.cpu.isalist' to ''setting
'user.home.url' to 'file:/root/':: loading settings :: url =
jar:[file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting|file://opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting]
'ivy.settings.url' to
[jira] [Updated] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
[
https://issues.apache.org/jira/browse/GROOVY-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9376:
--
Description:
Steps to reproduce inside docker. Repository added using GrabResolver is
completely ignored during resolution and fetching.
Manually putting repository location into ~/.groovy/grapeConfig.xml solves the
problem and make the custom repository work properly. Tested on Groovy 2.5.x
and Groovy 3.x, both have the same issue. This example comes from docker
container *groovy:3.0.0-rc-3-jre8*
*root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy**
*root@40bc8b504667:~# cat example.groovy*
{code}
#!/usr/bin/env groovy
@GrabResolver(name='restlet.org',
root='[http://maven.restlet.org')|http://maven.restlet.org%27%29/]
@Grab(group='org.restlet', module='org.restlet', version='1.1.6')
import org.restlet.Restlet;
{code}
*root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true
-Divy.message.logger.level=4 example.groovy*
setting 'ivy.default.settings.dir' to
'jar:file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting
'ivy.basedir' to '/root/.'setting 'ivy.default.conf.dir' to
'jar:file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting
'java.runtime.name' to 'OpenJDK Runtime Environment'setting
'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'setting
'java.vm.version' to '25.232-b09'setting 'groovy.grape.report.downloads' to
'true'setting 'java.vm.vendor' to 'AdoptOpenJDK'setting 'java.vendor.url' to
'http://java.oracle.com/'setting 'path.separator' to ':'setting 'java.vm.name'
to 'OpenJDK 64-Bit Server VM'setting 'file.encoding.pkg' to 'sun.io'setting
'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'setting
'sun.os.patch.level' to 'unknown'setting 'program.name' to 'groovy'setting
'java.vm.specification.name' to 'Java Virtual Machine Specification'setting
'user.dir' to '/root'setting 'java.runtime.version' to '1.8.0_232-b09'setting
'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'setting
'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'setting 'os.arch' to
'amd64'setting 'java.io.tmpdir' to '/tmp'setting 'line.separator' to ''setting
'java.vm.specification.vendor' to 'Oracle Corporation'setting 'os.name' to
'Linux'setting 'tools.jar' to '/opt/java/openjdk/lib/tools.jar'setting
'sun.jnu.encoding' to 'UTF-8'setting 'script.name' to '/usr/bin/groovy'setting
'java.library.path' to
'/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'setting
'java.specification.name' to 'Java Platform API Specification'setting
'java.class.version' to '52.0'setting 'sun.management.compiler' to 'HotSpot
64-Bit Tiered Compilers'setting 'os.version' to '5.4.0-3-amd64'setting
'user.home' to '/root'setting 'user.timezone' to ''setting
'java.awt.printerjob' to 'sun.print.PSPrinterJob'setting 'file.encoding' to
'UTF-8'setting 'java.specification.version' to '1.8'setting 'java.class.path'
to '/opt/groovy/lib/groovy-3.0.0-rc-3.jar'setting 'user.name' to 'root'setting
'ivy.message.logger.level' to '4'setting 'java.vm.specification.version' to
'1.8'setting 'sun.java.command' to 'org.codehaus.groovy.tools.GroovyStarter
--main groovy.ui.GroovyMain --conf /opt/groovy/conf/groovy-starter.conf
--classpath . -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
example.groovy'setting 'java.home' to '/opt/java/openjdk'setting
'sun.arch.data.model' to '64'setting 'user.language' to 'en'setting
'java.specification.vendor' to 'Oracle Corporation'setting 'awt.toolkit' to
'sun.awt.X11.XToolkit'setting 'java.vm.info' to 'mixed mode'setting
'java.version' to '1.8.0_232'setting 'java.ext.dirs' to
'/opt/java/openjdk/lib/ext:/usr/java/packages/lib/ext'setting
'sun.boot.class.path' to
'/opt/java/openjdk/lib/resources.jar:/opt/java/openjdk/lib/rt.jar:/opt/java/openjdk/lib/sunrsasign.jar:/opt/java/openjdk/lib/jsse.jar:/opt/java/openjdk/lib/jce.jar:/opt/java/openjdk/lib/charsets.jar:/opt/java/openjdk/lib/jfr.jar:/opt/java/openjdk/classes'setting
'java.vendor' to 'AdoptOpenJDK'setting 'file.separator' to '/'setting
'groovy.jaxb' to 'jaxb'setting 'java.vendor.url.bug' to
'http://bugreport.sun.com/bugreport/'setting 'sun.io.unicode.encoding' to
'UnicodeLittle'setting 'sun.cpu.endian' to 'little'setting
'groovy.starter.conf' to '/opt/groovy/conf/groovy-starter.conf'setting
'groovy.home' to '/opt/groovy'setting 'sun.cpu.isalist' to ''setting
'user.home.url' to 'file:/root/':: loading settings :: url =
jar:file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting
'ivy.settings.url' to
'jar:file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting
'ivy.conf.url' to
'jar:file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting
'ivy.settings.dir' to
[jira] [Commented] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024623#comment-17024623
]
Christoph Dreis commented on GROOVY-9211:
-
Thanks, but to the best of my knowledge 3.0.0 is not GA, yet!? Personally, I'm
more blocked by the Gradle issue
([https://github.com/gradle/gradle/issues/10248]) mentioned in a previous
comment. Gradle 6.1.1 uses Groovy 2.5.8, so the real question is if there are
any plans to backport the JDK 14 support to 2.5.x (which was also asked in
multiple previous comments)? I should have been more specific, sorry.
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024616#comment-17024616
]
Daniel Sun commented on GROOVY-9211:
[~christoph.dreis] Groovy 3.0.0 should support JDK 14, you can give it a try ;)
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9376) Groovy completely ignores @GrabResolver annotation
Damian Szuberski created GROOVY-9376: Summary: Groovy completely ignores @GrabResolver annotation Key: GROOVY-9376 URL: https://issues.apache.org/jira/browse/GROOVY-9376 Project: Groovy Issue Type: Bug Reporter: Damian Szuberski Steps to reproduce inside docker. Repository added using GrabResolver is completely ignored during resolution and fetching. Manually putting repository location into ~/.groovy/grapeConfig.xml solves the problem and make the custom repository work properly. Tested on Groovy 2.5.x and Groovy 3.x, both have the same issue. This example comes from docker container *groovy:3.0.0-rc-3-jre8* *root@40bc8b504667:~# rm -rf ~/.ivy* ~/.groovy** *root@40bc8b504667:~# cat example.groovy* #!/usr/bin/env groovy @GrabResolver(name='restlet.org', root='[http://maven.restlet.org')|http://maven.restlet.org%27%29/] @Grab(group='org.restlet', module='org.restlet', version='1.1.6') import org.restlet.Restlet; *root@40bc8b504667:~# groovy -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4 example.groovy* setting 'ivy.default.settings.dir' to 'jar:file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting 'ivy.basedir' to '/root/.'setting 'ivy.default.conf.dir' to 'jar:file:/opt/groovy/lib/ivy-2.5.0.jar!/org/apache/ivy/core/settings'setting 'java.runtime.name' to 'OpenJDK Runtime Environment'setting 'sun.boot.library.path' to '/opt/java/openjdk/lib/amd64'setting 'java.vm.version' to '25.232-b09'setting 'groovy.grape.report.downloads' to 'true'setting 'java.vm.vendor' to 'AdoptOpenJDK'setting 'java.vendor.url' to 'http://java.oracle.com/'setting 'path.separator' to ':'setting 'java.vm.name' to 'OpenJDK 64-Bit Server VM'setting 'file.encoding.pkg' to 'sun.io'setting 'user.country' to 'US'setting 'sun.java.launcher' to 'SUN_STANDARD'setting 'sun.os.patch.level' to 'unknown'setting 'program.name' to 'groovy'setting 'java.vm.specification.name' to 'Java Virtual Machine Specification'setting 'user.dir' to '/root'setting 'java.runtime.version' to '1.8.0_232-b09'setting 'java.awt.graphicsenv' to 'sun.awt.X11GraphicsEnvironment'setting 'java.endorsed.dirs' to '/opt/java/openjdk/lib/endorsed'setting 'os.arch' to 'amd64'setting 'java.io.tmpdir' to '/tmp'setting 'line.separator' to ''setting 'java.vm.specification.vendor' to 'Oracle Corporation'setting 'os.name' to 'Linux'setting 'tools.jar' to '/opt/java/openjdk/lib/tools.jar'setting 'sun.jnu.encoding' to 'UTF-8'setting 'script.name' to '/usr/bin/groovy'setting 'java.library.path' to '/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib'setting 'java.specification.name' to 'Java Platform API Specification'setting 'java.class.version' to '52.0'setting 'sun.management.compiler' to 'HotSpot 64-Bit Tiered Compilers'setting 'os.version' to '5.4.0-3-amd64'setting 'user.home' to '/root'setting 'user.timezone' to ''setting 'java.awt.printerjob' to 'sun.print.PSPrinterJob'setting 'file.encoding' to 'UTF-8'setting 'java.specification.version' to '1.8'setting 'java.class.path' to '/opt/groovy/lib/groovy-3.0.0-rc-3.jar'setting 'user.name' to 'root'setting 'ivy.message.logger.level' to '4'setting 'java.vm.specification.version' to '1.8'setting 'sun.java.command' to 'org.codehaus.groovy.tools.GroovyStarter --main groovy.ui.GroovyMain --conf /opt/groovy/conf/groovy-starter.conf --classpath . -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4 example.groovy'setting 'java.home' to '/opt/java/openjdk'setting 'sun.arch.data.model' to '64'setting 'user.language' to 'en'setting 'java.specification.vendor' to 'Oracle Corporation'setting 'awt.toolkit' to 'sun.awt.X11.XToolkit'setting 'java.vm.info' to 'mixed mode'setting 'java.version' to '1.8.0_232'setting 'java.ext.dirs' to '/opt/java/openjdk/lib/ext:/usr/java/packages/lib/ext'setting 'sun.boot.class.path' to '/opt/java/openjdk/lib/resources.jar:/opt/java/openjdk/lib/rt.jar:/opt/java/openjdk/lib/sunrsasign.jar:/opt/java/openjdk/lib/jsse.jar:/opt/java/openjdk/lib/jce.jar:/opt/java/openjdk/lib/charsets.jar:/opt/java/openjdk/lib/jfr.jar:/opt/java/openjdk/classes'setting 'java.vendor' to 'AdoptOpenJDK'setting 'file.separator' to '/'setting 'groovy.jaxb' to 'jaxb'setting 'java.vendor.url.bug' to 'http://bugreport.sun.com/bugreport/'setting 'sun.io.unicode.encoding' to 'UnicodeLittle'setting 'sun.cpu.endian' to 'little'setting 'groovy.starter.conf' to '/opt/groovy/conf/groovy-starter.conf'setting 'groovy.home' to '/opt/groovy'setting 'sun.cpu.isalist' to ''setting 'user.home.url' to 'file:/root/':: loading settings :: url = jar:file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xmlsetting 'ivy.settings.url' to 'jar:file:/opt/groovy/lib/groovy-3.0.0-rc-3.jar!/groovy/grape/defaultGrapeConfig.xml'setting 'ivy.conf.url' to
[jira] [Created] (GROOVY-9375) Cannot call method with Map parameter
Daniil Ovchinnikov created GROOVY-9375:
--
Summary: Cannot call method with Map parameter
Key: GROOVY-9375
URL: https://issues.apache.org/jira/browse/GROOVY-9375
Project: Groovy
Issue Type: Bug
Components: Static Type Checker
Affects Versions: 2.5.9
Reporter: Daniil Ovchinnikov
{code}
def foo(Map> m) { m }
@groovy.transform.CompileStatic
def csUsage() {
Map inner = new LinkedHashMap<>()
inner.put("b", 42)
Map> outer = new LinkedHashMap<>()
outer.put("a", inner)
foo(outer)
foo(a: inner)// error
foo(a: [b: 42]) // error
foo([a: [b: 42]])// error
}
csUsage()
{code}
The same error is reported on the lines with {{error}} comment:
{noformat}
[Static type checking] - Cannot call script#foo(java.util.Map
) with arguments [java.util.LinkedHashMap
]
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9375) Cannot call method with Map parameter
[
https://issues.apache.org/jira/browse/GROOVY-9375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniil Ovchinnikov updated GROOVY-9375:
---
Description:
{code}
def foo(Map> m) { m }
@groovy.transform.CompileStatic
def csUsage() {
Map inner = new LinkedHashMap<>()
inner.put("b", 42)
Map> outer = new LinkedHashMap<>()
outer.put("a", inner)
foo(outer)
foo(a: inner)// error
foo(a: [b: 42]) // error
foo([a: [b: 42]])// error
}
csUsage()
{code}
Expected: no errors.
The same error is reported on the lines with {{error}} comment:
{noformat}
[Static type checking] - Cannot call script#foo(java.util.Map
) with arguments [java.util.LinkedHashMap
]
{noformat}
was:
{code}
def foo(Map> m) { m }
@groovy.transform.CompileStatic
def csUsage() {
Map inner = new LinkedHashMap<>()
inner.put("b", 42)
Map> outer = new LinkedHashMap<>()
outer.put("a", inner)
foo(outer)
foo(a: inner)// error
foo(a: [b: 42]) // error
foo([a: [b: 42]])// error
}
csUsage()
{code}
The same error is reported on the lines with {{error}} comment:
{noformat}
[Static type checking] - Cannot call script#foo(java.util.Map
) with arguments [java.util.LinkedHashMap
]
{noformat}
> Cannot call method with Map parameter
> -
>
> Key: GROOVY-9375
> URL: https://issues.apache.org/jira/browse/GROOVY-9375
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.5.9
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code}
> def foo(Map> m) { m }
> @groovy.transform.CompileStatic
> def csUsage() {
> Map inner = new LinkedHashMap<>()
> inner.put("b", 42)
> Map> outer = new LinkedHashMap<>()
> outer.put("a", inner)
> foo(outer)
> foo(a: inner)// error
> foo(a: [b: 42]) // error
> foo([a: [b: 42]])// error
> }
> csUsage()
> {code}
> Expected: no errors.
> The same error is reported on the lines with {{error}} comment:
> {noformat}
> [Static type checking] - Cannot call script#foo(java.util.Map
> ) with arguments [java.util.LinkedHashMap
> ]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9211) BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
[
https://issues.apache.org/jira/browse/GROOVY-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024365#comment-17024365
]
Christoph Dreis commented on GROOVY-9211:
-
Hi everybody. Is there any progress on this, given that JDK 14 is approaching?
> BUG! UNCAUGHT EXCEPTION on OpenJDK14-ea+8
> -
>
> Key: GROOVY-9211
> URL: https://issues.apache.org/jira/browse/GROOVY-9211
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.7
> Environment: openjdk version "14-ea" 2020-03-17
> OpenJDK Runtime Environment (build 14-ea+8-255)
> OpenJDK 64-Bit Server VM (build 14-ea+8-255, mixed mode, sharing)
>Reporter: Piotr Zygielo
>Priority: Minor
>
> Change in JDK14 (ea+7..ea+8):
> [8173978:
> Lookup.in...|https://github.com/openjdk/jdk/commit/88d224f8f07#diff-7682d0273af974479e32f0f1d8684e63L782]
> +
> [Java7.java|https://github.com/apache/groovy/blob/5917828e1f3550a674ff0c4a57e67438fcc4258a/src/main/java/org/codehaus/groovy/vmplugin/v7/Java7.java#L43]
> =
> {code:java}
> Exception org.codehaus.groovy.GroovyBugError: BUG! UNCAUGHT EXCEPTION:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Java7. (Java7.java:45)
> at NativeConstructorAccessorImpl.newInstance0 (Native Method)
> at NativeConstructorAccessorImpl.newInstance
> (NativeConstructorAccessorImpl.java:62)
> at DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:45)
> at Constructor.newInstanceWithCaller (Constructor.java:500)
> at ReflectAccess.newInstance (ReflectAccess.java:124)
> at ReflectionFactory.newInstance (ReflectionFactory.java:346)
> at Class.newInstance (Class.java:591)
> at (#3:1)
> Caused by: java.lang.NoSuchMethodException:
> java.lang.invoke.MethodHandles$Lookup.(java.lang.Class,int)
> at Class.getConstructor0 (Class.java:3350)
> at Class.getDeclaredConstructor (Class.java:2554)
> at Java7. (Java7.java:43)
> {code}
> It happens in my maven build, during {{VMPluginFactory.}}
> I understand EA is EA, and even this given java is announced as build from
> the future, so this report is just to let you know.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GROOVY-9374) Type-inference fails for tap on inner classes with type checking
Jan Hackel created GROOVY-9374:
--
Summary: Type-inference fails for tap on inner classes with type
checking
Key: GROOVY-9374
URL: https://issues.apache.org/jira/browse/GROOVY-9374
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.9
Environment: Groovy 2.5.9. on Zulu JDK 11.0.3; Linux
Reporter: Jan Hackel
The following code will not compile with Groovy 2.5.9. It produces an error
"[Static type checking] - Cannot assign value of type java.lang.Object to
variable of type java.time.LocalDate". Same thing happens for instance fields.
A workaround is to qualify the source field either by {{this}} or by class name.
{code:groovy}
import groovy.transform.CompileStatic
import java.time.LocalDate
@CompileStatic
class TapTypeChecking {
private static final LocalDate DATE = LocalDate.of(2020, 2, 1)
static Inner inner() {
return new Inner().tap {
someDate = DATE
}
}
static class Inner {
LocalDate someDate
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-5490) Double Dispatch Distance Algorithm Incorrectly Implemented
[
https://issues.apache.org/jira/browse/GROOVY-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-5490:
--
Fix Version/s: (was: 3.x)
4.x
> Double Dispatch Distance Algorithm Incorrectly Implemented
> --
>
> Key: GROOVY-5490
> URL: https://issues.apache.org/jira/browse/GROOVY-5490
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.8.4, 2.4.3
>Reporter: thurston n
>Priority: Major
> Fix For: 4.x
>
>
> The following script
> {code:borderStyle=solid}
>1. static foo(Object o, Integer i) { "Integer won" }
> 2. static foo(String s, Object o) { "String won" }
> assert foo("potato", new Integer(6)) =~ "Integer"
> {code}
> fails.
> According to J. Theodorou, method resolution in Groovy employs a minimum
> _distance_ algorithm in determining which concrete method to invoke at
> runtime.
> The _distance_ of a single method parameter being computed as:
> distance(Class runtime, Class declaredParameter) ==> difference in level in
> inheritance tree, e.g. distance(String, Object) == 1 - 0 == 1, etc.
> therefore the total distance is just distance(param1) + distance(param2) + ...
> In the sample code above, the runtime distance of foo #1 would be
> (distance(String, Object) + distance(Integer, Integer)) == 1 + 0 == 1
> while distance of foo #2 would be (distance(String, String) +
> distance(Integer, Object)) == 0 + 2 == 2 (since Integer -> Number -> Object)
> Therefore foo #1 should have been selected
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-1569) correct closure property access to field access the same way it is done this.x
[
https://issues.apache.org/jira/browse/GROOVY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-1569:
--
Fix Version/s: (was: 3.x)
4.x
> correct closure property access to field access the same way it is done this.x
> --
>
> Key: GROOVY-1569
> URL: https://issues.apache.org/jira/browse/GROOVY-1569
> Project: Groovy
> Issue Type: Sub-task
> Components: class generator
>Reporter: Jochen Theodorou
>Priority: Major
> Fix For: 4.x
>
>
> this code:
> {code}
> class A {
> private foo = 1
> def getFoo(){
> 10.times { println this.foo }
> return this.foo+1
> }
> }
> def a = new A()
> println a.foo
> {code}
> should not end in a stack overflow
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-5513) Set - Collection has quadratic complexity
[ https://issues.apache.org/jira/browse/GROOVY-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-5513: -- Fix Version/s: (was: 3.x) 4.x > Set - Collection has quadratic complexity > - > > Key: GROOVY-5513 > URL: https://issues.apache.org/jira/browse/GROOVY-5513 > Project: Groovy > Issue Type: Improvement > Components: groovy-jdk >Reporter: Peter Gromov >Priority: Major > Fix For: 4.x > > > org.codehaus.groovy.runtime.DefaultGroovyMethods#minus(Set self, > Collection removeMe)'s complexity is O(m*n). If you used something like > THashSet > (http://trove4j.sourceforge.net/javadocs/gnu/trove/set/hash/THashSet.html) > you could make it O(m+n) by plugging in a smart hashing strategy. Perhaps you > already have something similar in your codebase or dependencies? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-1762) Add event introspection to the MetaClass
[
https://issues.apache.org/jira/browse/GROOVY-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-1762:
--
Fix Version/s: (was: 3.x)
4.x
> Add event introspection to the MetaClass
>
>
> Key: GROOVY-1762
> URL: https://issues.apache.org/jira/browse/GROOVY-1762
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 1.0
>Reporter: Daniel Ferrin
>Priority: Minor
> Fix For: 4.x
>
> Attachments: MetaClassGroovyTest.groovy, MetaEvent.java,
> MetaEvent.java, groovy-1762-diff.txt, groovy-1762-diff.txt
>
>
> There is no means to determine which events an object can accept closures
> for. As an example the snippet button.actionPerformed = {
> doButtonAction()) would require the user to know that one of the
> listener methods on JButton is an ActionListener with an actionPerfomed
> method, but there is no programatic way to introspect that pseudo property.
> The soluition would be to extend MetaMethod with the needed fields to provide
> sensible information about the event, and enumerate that in the MetaClass via
> a getEvents() method.
> Implementation forthcoming...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-2768) Add sender of method calls as a parameter to the methods of MetaClass
[ https://issues.apache.org/jira/browse/GROOVY-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2768: -- Fix Version/s: (was: 3.x) 4.x > Add sender of method calls as a parameter to the methods of MetaClass > - > > Key: GROOVY-2768 > URL: https://issues.apache.org/jira/browse/GROOVY-2768 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Reporter: Arvid Heise >Priority: Minor > Fix For: 4.x > > > MetaClass extends the MOP interface with methods which have a senderClass as > their first parameter. Unfortunately, the param does not refer to the sender > of the original method call but is in most cases identical to the receiver's > class. > Knowing the sender of a method call would allow interesting reflective > program structures like subjective programming with a three-dimensional > message dispatch. A method can not only be overwritten by the receiver with > polymorphism but also by the sender. Refer to > http://citeseer.ist.psu.edu/smith96simple.html for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-6898) Changes to metaclasses should not leak into subsequent script executions
[
https://issues.apache.org/jira/browse/GROOVY-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-6898:
--
Fix Version/s: (was: 3.x)
4.x
> Changes to metaclasses should not leak into subsequent script executions
>
>
> Key: GROOVY-6898
> URL: https://issues.apache.org/jira/browse/GROOVY-6898
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.3.2
>Reporter: Jochen Kemnade
>Priority: Major
> Fix For: 4.x
>
>
> This is roughly related to GROOVY-5786.
> When executing a script in the Groovy ScriptEngine (the JSR223 one) and that
> script makes changes to the metaclass registry, the modification will be
> available to the next script.
> For example, If I execute
> {code}
> String.metaClass {
> foobar ={
> delegate
> }
> }
> print("Hello".foobar())
> {code}
> the script prints {{"Hello"}}.
> If I execute
> {code}
> print("Hello".foobar())
> {code}
> in the same engine again, it prints {{"Hello"}} again. I think it should
> throw a {{MissingMethodException}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-5946) Uninformative error message (stack trace) when adding a custom annotation
[
https://issues.apache.org/jira/browse/GROOVY-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-5946:
--
Fix Version/s: (was: 3.x)
4.x
> Uninformative error message (stack trace) when adding a custom annotation
> -
>
> Key: GROOVY-5946
> URL: https://issues.apache.org/jira/browse/GROOVY-5946
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 2.0.6, 2.1.0-rc-3, 2.1.0
> Environment: OSX, Gradle or IntelliJ compile or Maven eclipse compiler
>Reporter: Scott Murphy
>Priority: Major
> Fix For: 4.x
>
>
> Adding the Gaelyk annotation @Entity results in a stack trace during
> compilation. In addition, no informative message is given as to which groovy
> file caused the issue.
> At the very least, a more explicative message (not a stack trace) should be
> given to the user as well as informing the user which file could not be
> compile.
> In a more general case, any stack trace that is thrown should have a message
> included with it stating the offending file name.
> Example:
> {code}
> @Entity
> class Favorite {
> ÃâàÃâàDate created
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-2857) Full support for special characters in method names
[ https://issues.apache.org/jira/browse/GROOVY-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2857: -- Fix Version/s: 4.x > Full support for special characters in method names > --- > > Key: GROOVY-2857 > URL: https://issues.apache.org/jira/browse/GROOVY-2857 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Affects Versions: 1.6-beta-2 > Environment: Mac OS 10.5.2 > JDK 1.5.0_13 > Groovy 1.6-beta-2-SNAPSHOT >Reporter: Peter Niederwieser >Priority: Major > Fix For: 4.x > > > Groovy allows method names to be specified as String literals. This enables > the use of special characters in method names, such as space, comma, and > question mark. However, when such a name become part of a class name, a > "java.lang.ClassFormatError: Illegal class name" is thrown at runtime. As far > as I can tell, this happens when: > 1. closures are involved > 2. the new call site mechanism generates a class on-the-fly > To fully support special characters in method names, the naming scheme of > generated classes should thus be adapted. Also, the (few) characters that > aren't allowed to appear in a method name according to the JVM specification > should be rejected by the parser. For more information and related discussion > see: > http://groups.google.com/group/jvm-languages/browse_thread/thread/c5c9c0bafe1ef0c8 > http://www.nabble.com/In-Love-with-Groovy-tt17240709.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-2857) Full support for special characters in method names
[ https://issues.apache.org/jira/browse/GROOVY-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2857: -- Fix Version/s: (was: 3.x) > Full support for special characters in method names > --- > > Key: GROOVY-2857 > URL: https://issues.apache.org/jira/browse/GROOVY-2857 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Affects Versions: 1.6-beta-2 > Environment: Mac OS 10.5.2 > JDK 1.5.0_13 > Groovy 1.6-beta-2-SNAPSHOT >Reporter: Peter Niederwieser >Priority: Major > > Groovy allows method names to be specified as String literals. This enables > the use of special characters in method names, such as space, comma, and > question mark. However, when such a name become part of a class name, a > "java.lang.ClassFormatError: Illegal class name" is thrown at runtime. As far > as I can tell, this happens when: > 1. closures are involved > 2. the new call site mechanism generates a class on-the-fly > To fully support special characters in method names, the naming scheme of > generated classes should thus be adapted. Also, the (few) characters that > aren't allowed to appear in a method name according to the JVM specification > should be rejected by the parser. For more information and related discussion > see: > http://groups.google.com/group/jvm-languages/browse_thread/thread/c5c9c0bafe1ef0c8 > http://www.nabble.com/In-Love-with-Groovy-tt17240709.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-3015) Seems like ClosureMetaClass#invokeMethod does not respect the interceptable nature of the owner/delegate
[
https://issues.apache.org/jira/browse/GROOVY-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3015:
--
Fix Version/s: (was: 3.x)
4.x
> Seems like ClosureMetaClass#invokeMethod does not respect the interceptable
> nature of the owner/delegate
>
>
> Key: GROOVY-3015
> URL: https://issues.apache.org/jira/browse/GROOVY-3015
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.5.6
> Environment: Windows XP
>Reporter: Erick Erickson
>Priority: Major
> Fix For: 4.x
>
>
> Sample program and output. The closure and the method both call 'outer'
> which calls 'inner', but the closure does NOT trace the call to 'outer'
> See comments, including Jochen "blackdrag" Theodorou's at
> http://www.nabble.com/implementing-GroovyInterceptable-behaves-differently-in-closures-and-methods-td19072057.html
> program output
> Entering shouldTraceOuterAndInnerClosure
> Entering inner
> Leaving inner
> Leaving shouldTraceOuterAndInnerClosure
> Entering shouldTraceOuterAndInnerMethod
> Entering outer
> Entering inner
> Leaving inner
> Leaving outer
> Leaving shouldTraceOuterAndInnerMethod
> *end program output
> code starts
> import org.codehaus.groovy.runtime.StringBufferWriter
> import org.codehaus.groovy.runtime.InvokerHelper
> class Traceable implements GroovyInterceptable {
> private static int indent = 1
> Writer writer = new PrintWriter(System.out)
> Object invokeMethod(String name, Object args) {
> def result
> def metaClass = InvokerHelper.getMetaClass(this)
> writer.write("\n" + ' ' * indent + "Entering $name")
> ++indent
> result = metaClass.invokeMethod(this, name, args)
> --indent
> writer.write("\n" + ' ' * indent + "Leaving $name")
> return result
> }
> }
> class Whatever extends Traceable {
> int outer() {
> return inner()
> }
> int inner() {
> return 1
> }
> def shouldTraceOuterAndInnerClosure = {
> return outer()
> }
>
> int shouldTraceOuterAndInnerMethod() {
> return outer()
> }
> }
> def log = new StringBuffer()
> def traceMe = new Whatever(writer : new StringBufferWriter(log))
> traceMe.shouldTraceOuterAndInnerClosure()
> traceMe.shouldTraceOuterAndInnerMethod()
> println log.toString()
> *program ends**
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-2310) ExpandoMetaClass does not offer a consistent way to retrieve and invoke overloaded methods
[
https://issues.apache.org/jira/browse/GROOVY-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-2310:
--
Fix Version/s: (was: 3.x)
> ExpandoMetaClass does not offer a consistent way to retrieve and invoke
> overloaded methods
> --
>
> Key: GROOVY-2310
> URL: https://issues.apache.org/jira/browse/GROOVY-2310
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 1.1-rc-2
>Reporter: Marc Palmer
>Priority: Major
>
> As discussed with Graeme, take a Grails plugin for example that might supply
> a proxy "render" method for controllers, that checks for certain parameters
> and if present does something, else defers to the pre-existing render()
> method. There are several default render(...) variants overloaded, but this
> plugin replaces only a specific one:
> {code}
> def oldRender = controllerClass.metaClass.render
> controllerClass.metaClass.render = { Map m, Closure c ->
> if (!something) oldRender(m, c)
> }
> {code}
> This may work sometimes if the render method retrieved from the EMC is the
> one that takes Map, Closure. Sometimes it may not be though, and then you get
> method invocation errors when it tries to pass in the Map and Closure.
> Currently the workaround is to use metaClass.getMetaMethod( name, argTypes)
> but this gives you a different invocation paradigm - i.e. you must call
> invoke() on the MetaMethod.
> A couple of features then offer themselves as part or whole solutions:
> # Make MetaMethod support call()/doCall() as well as invoke()
> # Make EMC's methodMissing return a new MultiMetaMethodProxy object that,
> when call() is invoked, automatically determines which overloaded method to
> invoke. This could be dangerous, needs further assessment. This is the most
> elegant approach in my opinion, but I don't believe anywhere else in groovy
> treats all overloaded forms of a method as a "single" method and as such the
> terminology may not work. The concept is great, but maybe Groovy needs a new
> term for this, such as "Message" as in other OO languages. i.e. a MetaMessage
> is some invokation you can perform on an object using MetaMessage.call(args)
> but the exact method that will be called is dependent on the args, i.e. it
> knows about all the possible MetaMethods.
> # Add a new findMethod(name, argTypes) that returns a method reference
> instead of MetaMethod.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-3309) comparisons with NaN should always return false
[
https://issues.apache.org/jira/browse/GROOVY-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3309:
--
Fix Version/s: (was: 3.x)
4.x
> comparisons with NaN should always return false
> ---
>
> Key: GROOVY-3309
> URL: https://issues.apache.org/jira/browse/GROOVY-3309
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.5.7, 1.6-rc-2
> Environment: os x, jse 5 and 6
>Reporter: Andy Fyfe
>Priority: Major
> Fix For: 4.x
>
>
> The following assertions should all pass; the third fails.
> {code}
> assert !(Double.NaN == 0)
> assert !(Double.NaN < 0)
> assert !(Double.NaN > 0)
> {code}
> A NaN should also not equal a NaN.
> {code}assert Double.NaN != Double.NaN{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GROOVY-5450) Final field assignment check on static compilation
[
https://issues.apache.org/jira/browse/GROOVY-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14472846#comment-14472846
]
Paul King edited comment on GROOVY-5450 at 1/27/20 10:45 AM:
-
This is also related to GROOVY-4681, which addresses the issue for local
variables.
was (Author: rgarcia):
This is also related to
[GROOVY-4681|http://jira.codehaus.org/browse/GROOVY-4681], which addresses the
issue for local variables.
> Final field assignment check on static compilation
> --
>
> Key: GROOVY-5450
> URL: https://issues.apache.org/jira/browse/GROOVY-5450
> Project: Groovy
> Issue Type: New Feature
> Components: Compiler
>Affects Versions: 2.0-beta-3
>Reporter: Renato Garcia
>Priority: Major
> Labels: contrib
> Fix For: 3.x
>
>
> The following class definition should generate a compilation error on final
> field assignment.
> {code}
> @CompileStatic
> class StaticGroovy3 {
> def testFinalField() {
> new FinalField().aField = ""
> }
> }
> class FinalField {
> final aField;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-6979) metaClass.getMetaMethod doesn't find method with Class as an argument
[
https://issues.apache.org/jira/browse/GROOVY-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-6979:
--
Fix Version/s: (was: 3.x)
4.x
> metaClass.getMetaMethod doesn't find method with Class as an argument
> -
>
> Key: GROOVY-6979
> URL: https://issues.apache.org/jira/browse/GROOVY-6979
> Project: Groovy
> Issue Type: Sub-task
> Components: groovy-runtime
>Affects Versions: 2.1.9, 2.2.2, 2.4.0-beta-1, 2.3.5
>Reporter: Martin Schayna
>Priority: Major
> Fix For: 4.x
>
>
> Method with argument of type Class cannot be found by
> metaClass.getMetaMethod():
> {code:java}
> class A {
> // cannot be found by getMetaMethod
> def met1(Class clazz) {
> println clazz.name
> }
> // a workaround
> def met2(List clazz) {
> println clazz.get(0).name
> }
> }
> A.metaClass.invokeMethod = { name, args ->
> def metaMethod = delegate.metaClass.getMetaMethod(name, args)
> if (metaMethod) {
> metaMethod.invoke(delegate, args)
> } else {
> println "Method $name not found on $delegate"
> }
> }
> def a = new A()
> a.met1(A) // prints Method met1 not found on A@1c804...
> a.met2([A]) // prints A
> {code}
> It could be caused by ambiguous nature of *getMetaMethod* which accepts array
> of Object or Class as well, in case of Class as an argument it cannot find
> method correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-5367) Closure property in Binding used as Closure delegate cannot be called
[
https://issues.apache.org/jira/browse/GROOVY-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-5367:
--
Fix Version/s: (was: 3.x)
4.x
> Closure property in Binding used as Closure delegate cannot be called
> -
>
> Key: GROOVY-5367
> URL: https://issues.apache.org/jira/browse/GROOVY-5367
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.8.6
>Reporter: Wujek
>Priority: Major
> Fix For: 4.x
>
>
> In a script, this works:
> c = { println 'works' }
> c()
> whereas this one doesn't:
> def bind = new Binding(c: { println 'does not work' })
> def t = { c() }
> t.delegate = bind
> t()
> They both define a 'c' property in the binding which happens to be a closure.
> In the first case, the closure get's called as Groovy apparently tries to get
> the binding property and invoke it if it's a closure; in the latter, the
> delegate of the closure is a binding with a property 'c' that is a closure,
> but c() still doesn't work.
> I debugged this and there is actually an if in MetaClassImpl that checks if
> the 'this' object is a Script, and if so, a property with the name is
> retrieved and a call() method is called.
> (MetaClassImpl#invokePropertyOrMissing:1089 in Groovy 1.8.6-all from maven
> central).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-8875) NullObject.metaClass
[
https://issues.apache.org/jira/browse/GROOVY-8875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8875:
--
Fix Version/s: (was: 3.x)
> NullObject.metaClass
>
>
> Key: GROOVY-8875
> URL: https://issues.apache.org/jira/browse/GROOVY-8875
> Project: Groovy
> Issue Type: Bug
>Reporter: Pruteanu Dragos
>Priority: Major
>
> Hi,
> I execute this. The third shell.evaluate throws an exception:
> {code}
> final GroovyShell shell = new GroovyShell( binding,
> FormsGroovyConfiguration.CONFIG );
> // THIS WILL FORCE NULL VARIABLES TO PRINT AS '' INSTEAD OF NULL
> //
> http://stackoverflow.com/questions/10517817/how-to-get-rid-of-null-when-concating-string-in-groovy
> shell.evaluate("org.codehaus.groovy.runtime.NullObject.metaClass.toString = {
> return '' }");
> {code}
> And got the next exception. This used to work in Java 10 and before, it
> crashes under Java 11. Could have something to do with java modules ?
> {noformat}
> Exception in thread "JavaFX Application Thread" BUG! exception in phase
> 'semantic analysis' in source unit 'Script1.groovy' null
> at
> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:970)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:633)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:582)
> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:324)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:294)
> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:558)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:570)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:454)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:493)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:464)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-4583) Ability to get class bytes of closures at runtime, including nested closures (for remote control)
[ https://issues.apache.org/jira/browse/GROOVY-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4583: -- Fix Version/s: (was: 3.x) > Ability to get class bytes of closures at runtime, including nested closures > (for remote control) > - > > Key: GROOVY-4583 > URL: https://issues.apache.org/jira/browse/GROOVY-4583 > Project: Groovy > Issue Type: New Feature >Reporter: Luke Daley >Priority: Major > > The groovy remote project - http://groovy.codehaus.org/modules/remote/ - > works by sending the bytes of a closure class (and all nested closures) over > to the server to be used to define the class(es) there so the closure > instance can be unserialised and executed. > This currently works by searching the classpath for the closure .class files. > This doesn't work when the closures weren't compiled beforehand, such as when > using groovy from the command line or the groovy console. > It would be great to have a foolproof way of getting the bytes that define a > closure class and all the closure's it uses in a way that was agnostic to how > the closure was defined/compiled to use here. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-6285) static declared type should influence method selection for null values
[
https://issues.apache.org/jira/browse/GROOVY-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-6285:
--
Fix Version/s: (was: 3.x)
4.x
> static declared type should influence method selection for null values
> --
>
> Key: GROOVY-6285
> URL: https://issues.apache.org/jira/browse/GROOVY-6285
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-runtime
>Affects Versions: 2.1.6
>Reporter: frenchyan
>Priority: Major
> Fix For: 4.x
>
> Attachments: glu235.groovy
>
>
> See file attached to reproduce the problem: E1 is an exception class, E2
> extends from E1 but define only the constructor with {{String}}.
> using new E2(null) end up calling {{E1(Throwable)}} => calling {{initCause}}
> then fails because the cause has been already been set.
> I am expecting {{E1(String)}} to be called...
> {code}
> > groovy -version
> Groovy Version: 2.1.6 JVM: 1.7.0_25 Vendor: Oracle Corporation OS: Mac OS X
> > groovy glu235.groovy
> called E1.throwable null
> called E2.string null
> Caught: java.lang.IllegalStateException: Can't overwrite cause
> java.lang.IllegalStateException: Can't overwrite cause
> at java_lang_Throwable$initCause.call(Unknown Source)
> at glu235.run(glu235.groovy:43)
> {code}
> Reproducible with groovy 2.0.7 as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-4694) Move AstBuilderTransformation Global xForm to separate module
[ https://issues.apache.org/jira/browse/GROOVY-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4694: -- Fix Version/s: (was: 3.x) 4.x > Move AstBuilderTransformation Global xForm to separate module > - > > Key: GROOVY-4694 > URL: https://issues.apache.org/jira/browse/GROOVY-4694 > Project: Groovy > Issue Type: Improvement > Components: ast builder >Affects Versions: 1.8-rc-1 >Reporter: Roshan Dawrani >Priority: Major > Fix For: 4.x > > > Hi, > Based on the dev mailing list thread: > http://markmail.org/message/aiwgmjywhqr5edud, this is a request to move > AstBuilderTransformation into a separate module, so that the general > compilation of the groovy scripts, which don't have anything to do with > AstBuilder, don't have to incur the cost of its processing. > I didn't really try to look for a general modularization effort JIRA. If > there is one, may be this issue can become a sub-task there. > Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-4032) Ability to persist meta methods
[ https://issues.apache.org/jira/browse/GROOVY-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4032: -- Fix Version/s: (was: 3.x) 4.x > Ability to persist meta methods > --- > > Key: GROOVY-4032 > URL: https://issues.apache.org/jira/browse/GROOVY-4032 > Project: Groovy > Issue Type: Improvement > Components: groovy-jdk >Affects Versions: 1.7.0 > Environment: eclipse ganymede > windows >Reporter: Matthew Corby-Eaglen >Priority: Major > Fix For: 4.x > > > Other languages, such as Lua, can persist dynamic methods: > http://luaforge.net/projects/pluto/ > example of how it works: > http://www.mudbytes.net/index.php?a=topic=1991 > In groovy, you cannot persist a meta method that you have dynamically added > to a class because the metaclass is not set up with the closure when > deserialization occurs. > I think it would be a good feature to implement, however it may be done. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-3952) CLONE -Groovy Support for annotations on local variable declarations: Part II - Allow Local Transforms to process such annotations
[
https://issues.apache.org/jira/browse/GROOVY-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3952:
--
Fix Version/s: (was: 3.x)
4.x
> CLONE -Groovy Support for annotations on local variable declarations: Part II
> - Allow Local Transforms to process such annotations
> --
>
> Key: GROOVY-3952
> URL: https://issues.apache.org/jira/browse/GROOVY-3952
> Project: Groovy
> Issue Type: New Feature
> Components: ast builder
>Affects Versions: 1.7.0
> Environment: All
>Reporter: Paul King
>Priority: Major
> Fix For: 4.x
>
>
> Groovy should support annotations on local variable declarations. It is
> syntactically legal to annotate a local variable, but the AST produced does
> not carry that annotation.
> My use case with the AST builder. Either we'd like to annotate a local
> variable, like this:
> {code}
> @AstSource(CompilePhase.CONVERSION)
> def source = { println "compiled on: ${new Date()}" }
> {code}
> Or annotate a property within a closure (which is a
> {{DeclarationExpression}}), like this:
> {code}
> def result = new AstBuilder().build {
>phase = CompilePhase.CONVERSION
>@AstSource
>source = { println "compiled on: ${new Date()}" }
> }
> {code}
> A {{getAnnotations()}} method should probably be added to
> {{DeclarationExpression}} to support this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-4502) Move Closure Class generation logic into a much earlier phase
[ https://issues.apache.org/jira/browse/GROOVY-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4502: -- Fix Version/s: (was: 3.x) 4.x > Move Closure Class generation logic into a much earlier phase > - > > Key: GROOVY-4502 > URL: https://issues.apache.org/jira/browse/GROOVY-4502 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Jochen Theodorou >Priority: Major > Fix For: 4.x > > > ClosureExpression should get a new field storing the class that will be used > for this expression, and also provide a static method for the class name > generation. the field should be set in APP already and the ClassNode added as > primary ClassNode to the compile unit. Possible problem here, > VariableScopeVisitor and maybe the StaticImoprtVisitor should skip the class > and instead still work on the expression contents. Here is potential for > breaking existing user code. The static method can be used by people adding > closures themselfes and wanting to keep the naming scheme. Since that usually > works using an count, a possible other place is in ClassNode as instance > method -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-6142) IllegalAccessError. Closures inside of methods with dots
[
https://issues.apache.org/jira/browse/GROOVY-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-6142:
--
Fix Version/s: (was: 3.x)
> IllegalAccessError. Closures inside of methods with dots
>
>
> Key: GROOVY-6142
> URL: https://issues.apache.org/jira/browse/GROOVY-6142
> Project: Groovy
> Issue Type: Improvement
> Components: class generator
>Affects Versions: 2.1.3
> Environment: Ubuntu Precise
>Reporter: stanislav bashkirtsev
>Priority: Major
>
> I have a Groovy JUnit test:
> {code:Java} @Test
> void 'challenge6. break xor key'(){
> List possibleCipherLengths = []
> possibleCipherLengths.each {}
> }{code}Notice a dot (.) in the name of test.
> *Actual Result*: It throws:
> {code}java.lang.IllegalAccessError: tried to access class
> bases.ChallengeTest$_challenge6._break_xor_key_closure5 from class
> bases.ChallengeTest
> at bases.ChallengeTest.challenge6. break xor
> key(ChallengeTest.groovy:88){code}If I remove the dot, then it's fine.
> *Expected Result*: if this is not allowed, the error should state what was
> wrong. If this syntax should be allowed (I don't see reasons why not), then
> no error should appear ;)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-4683) static import collection task
[ https://issues.apache.org/jira/browse/GROOVY-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4683: -- Fix Version/s: (was: 3.x) > static import collection task > - > > Key: GROOVY-4683 > URL: https://issues.apache.org/jira/browse/GROOVY-4683 > Project: Groovy > Issue Type: Task > Components: Compiler >Reporter: Jochen Theodorou >Priority: Major > > This is a task to collect static import related issues -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-3549) Usage of ".class" to disambiguate between methods
[
https://issues.apache.org/jira/browse/GROOVY-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3549:
--
Fix Version/s: (was: 3.x)
> Usage of ".class" to disambiguate between methods
> -
>
> Key: GROOVY-3549
> URL: https://issues.apache.org/jira/browse/GROOVY-3549
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 1.6.3
>Reporter: Peter Niederwieser
>Priority: Major
>
> From a programmer's perspective, it's clear that in the second example,
> Class.getName() should be called. Can we support this in 2.0?
> {code}
> class JavaLangClassUsageTest extends GroovyTestCase {
> void testCallFooGetNameMethod() {
> assert Foo.getName() == "Foo.getName" // passes
> }
> void testCallJavaLangClassGetNameMethod() {
> assert Foo.class.getName() == "Foo" // fails, actual: Foo.getName
> }
> }
> class Foo {
> static getName() { "Foo.getName" }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-3412) Method Caching within MethodMissing is not working
[
https://issues.apache.org/jira/browse/GROOVY-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3412:
--
Fix Version/s: (was: 3.x)
> Method Caching within MethodMissing is not working
> --
>
> Key: GROOVY-3412
> URL: https://issues.apache.org/jira/browse/GROOVY-3412
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 1.6, 2.4.3
> Environment: Ubuntu Linux, JDK 1.6, Eclipse 3.4
>Reporter: James Parkin
>Priority: Major
>
> The following code attempts to cache a method call within the methodMissing
> method, however in groovy 1.6, when the method is called for a second time
> the cached version is not being used. This code works fine in 1.5.7.
> {code}
> class PersonAgain
> {
> def work() { "working..." }
> def plays = ['Tennis', 'VolleyBall', 'BasketBall']
> def methodMissing(String name, args)
> {
> System.out.println "methodMissing called for $name"
> def methodInList = plays.find {it == name.split('play')[1] }
> if(methodInList)
> {
> def impl = { Object[] vargs ->
> return "playing ${name.split('play')[1]}..."
> }
>
> PersonAgain.metaClass."$name" = impl
> return impl(args)
> }
> else
> {
> throw new MissingMethodException(name,
> PersonAgain.class, args)
> }
> }
> static { PersonAgain.metaClass }
> }
> jack = new PersonAgain()
> println jack.playTennis()
> println jack.playTennis()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-3907) no way to get declared and dgm methods in one list
[ https://issues.apache.org/jira/browse/GROOVY-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-3907: -- Fix Version/s: (was: 3.x) > no way to get declared and dgm methods in one list > -- > > Key: GROOVY-3907 > URL: https://issues.apache.org/jira/browse/GROOVY-3907 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > > On MetaClass there seems to be getMethods() returning the available methods > declared through this or a super class (minus private ones), and > getMetaMethods() returning all DGM methods. What is missing is to have a > method that returns both. In fact the purpose of splitting is unclear to me. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-3299) Modifying meta-class has no effect in some cases
[ https://issues.apache.org/jira/browse/GROOVY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-3299: -- Priority: Major (was: Critical) > Modifying meta-class has no effect in some cases > > > Key: GROOVY-3299 > URL: https://issues.apache.org/jira/browse/GROOVY-3299 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 1.6-rc-1 >Reporter: Peter Ledbrook >Priority: Major > Fix For: 3.x > > Attachments: MetaClassCachingBugTests.groovy, > MetaClassCachingBugWithInterfaceTests.groovy > > > See the attach test case. Basically it seems that the meta class for a class > is cached, but if it is modified (for example via EMC syntax), the cached > version is not updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-3299) Modifying meta-class has no effect in some cases
[ https://issues.apache.org/jira/browse/GROOVY-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-3299: -- Fix Version/s: (was: 3.x) 4.x > Modifying meta-class has no effect in some cases > > > Key: GROOVY-3299 > URL: https://issues.apache.org/jira/browse/GROOVY-3299 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 1.6-rc-1 >Reporter: Peter Ledbrook >Priority: Major > Fix For: 4.x > > Attachments: MetaClassCachingBugTests.groovy, > MetaClassCachingBugWithInterfaceTests.groovy > > > See the attach test case. Basically it seems that the meta class for a class > is cached, but if it is modified (for example via EMC syntax), the cached > version is not updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-3351) Curried MethodClosure with default parameters wont work
[
https://issues.apache.org/jira/browse/GROOVY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3351:
--
Fix Version/s: (was: 3.x)
> Curried MethodClosure with default parameters wont work
> ---
>
> Key: GROOVY-3351
> URL: https://issues.apache.org/jira/browse/GROOVY-3351
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.0
>Reporter: Andres Almiray
>Priority: Major
>
> As detailed on this thread
> http://www.nabble.com/Curried-closures-with-default-parameters-td21906130.html
> currying a Methodclosure whose original method has default parameters and
> assigning it to a metaClass means the default parameters are lost, the
> workaround is to 'manually' curry the closure
> {code}
> class Foo {
>static fooWithDefaults( String a1, String a2, String a3 = a2, Map a4 = [:]
> ) { /*stuff*/ }
>static decorate( Class klass ) {
> klass.metaclass.foo = this.("A")
>}
> }
> def f = new Foo()
> f.foo("B") // throws MME
> f.foo("B","C",[:]) // works
> {code}
> workaround
> {code}
> class Foo {
>static fooWithDefaults( String a1, String a2, String a3 = a2, Map a4 = [:]
> ) { /*stuff*/ }
>static decorate( Class klass ) {
> klass.metaClass.foo = { String a2, String a3 = a2, Map a4 = [:] ->
> Foo.fooWithDefaults("A",a2,a3,a4)
> }
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-6182) Problem With getAt(Object)
[ https://issues.apache.org/jira/browse/GROOVY-6182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-6182: -- Fix Version/s: (was: 3.x) 4.x > Problem With getAt(Object) > -- > > Key: GROOVY-6182 > URL: https://issues.apache.org/jira/browse/GROOVY-6182 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.1.3 >Reporter: Jeff Brown >Priority: Minor > Fix For: 4.x > > Attachments: getat.zip > > > getAt(Object) does not appear to be called when I do something like > obj['someString']. If I statically type the argument like getAt(String key), > then it appears to work. I am not sure if this is a bug or not. > In the attached app run "./gradlew test". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-2521) keyword 'use' like 'import (static)' to use categories in a complete compilation unit
[
https://issues.apache.org/jira/browse/GROOVY-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-2521:
--
Fix Version/s: (was: 3.x)
4.x
> keyword 'use' like 'import (static)' to use categories in a complete
> compilation unit
> -
>
> Key: GROOVY-2521
> URL: https://issues.apache.org/jira/browse/GROOVY-2521
> Project: Groovy
> Issue Type: New Feature
>Reporter: Jörg Gottschling
>Priority: Major
> Fix For: 4.x
>
>
> I'd like to have a keyword 'use' which can be used at the beginning of a
> file, like a static import, but as category. So:
> The first example from http://groovy.codehaus.org/Groovy+Categories :
> import groovy.xml.*
> def html = /* ... */
> use (groovy.xml.dom.DOMCategory) {
> assert html.head.title.text() == 'Test'
> // ...
> }
> Would then become:
> import groovy.xml.*
> use groovy.xml.dom.DOMCategory
> def html = /* ... */
> assert html.head.title.text() == 'Test'
> assert html.body.p.text() == 'This is a test.'
> // ...
> I think this is extremely usefull when using a category in more then one
> method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-4339) Compiler first allows an annotation on a statement, then fails with a weird error message
[
https://issues.apache.org/jira/browse/GROOVY-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-4339:
--
Fix Version/s: (was: 3.x)
4.x
> Compiler first allows an annotation on a statement, then fails with a weird
> error message
> -
>
> Key: GROOVY-4339
> URL: https://issues.apache.org/jira/browse/GROOVY-4339
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Reporter: Roshan Dawrani
>Priority: Minor
> Fix For: 4.x
>
>
> {code}
> int i
> @Deprecated
> i = 2
> {code}
> Snippet above fails with
> {noformat}
> _.groovy: 4: The current scope already contains a variable of the name i
> @ line 4, column 1.
>i = 2
> {noformat}
> It should better say that an annotation is not allowed/handled where it is
> specified.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-7867) asType(Collection col, Class clazz) ingnores exceptions in clazz constructor
[
https://issues.apache.org/jira/browse/GROOVY-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-7867:
--
Fix Version/s: (was: 3.x)
4.x
> asType(Collection col, Class clazz) ingnores exceptions in clazz constructor
>
>
> Key: GROOVY-7867
> URL: https://issues.apache.org/jira/browse/GROOVY-7867
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.3, 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.8, 3.x,
> 2.5.0-beta-1
> Environment: no matter
>Reporter: Pavel Novichenko
>Priority: Major
> Fix For: 4.x
>
>
> Method ignores exception in clazz constructor, and if any - throws exception
> later, when try find constructor with args matches collection items.
> public static T asType(Collection col, Class clazz) in
> DefaultGroovyMethods.java, line 10623:
> {code:title=DefaultGroovyMethods.java|borderStyle=solid}
> Object[] args = {col};
> try {
> return (T) InvokerHelper.invokeConstructorOf(clazz, args);
> } catch (Exception e) {
> // ignore, the constructor that takes a Collection as an argument
> may not exist
> }
> {code}
> In my opinion, should ignore only if such constroctor not found
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-5363) MarkupBuilder and StreamingMarkupBuilder should merge
[ https://issues.apache.org/jira/browse/GROOVY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-5363: -- Fix Version/s: (was: 3.x) 4.x > MarkupBuilder and StreamingMarkupBuilder should merge > - > > Key: GROOVY-5363 > URL: https://issues.apache.org/jira/browse/GROOVY-5363 > Project: Groovy > Issue Type: Bug > Components: XML Processing >Affects Versions: 2.0-beta-2 >Reporter: Dr. Russel Winder >Priority: Major > Labels: contrib > Fix For: 4.x > > > Currently there is MarkupBuilder and StreamingMarkupBuilder. These should be > different implementations of the same interface. The choice of streaming or > non-streaming should be a constructor parameter or static virtual constructor > parameter, not a difference in (visible) class name. > The design should factor in JDK8's stream capabilities. > Assuming Groovy adds support for Java9 modules, this class would likely > reside in a new XML module along with a revamped slurper/parser. While > designing the module system or setting up the envisaged XML module aren't > really within scope of this issue, it would be good to factor in the > requirements we know for JDK9's module capabilities, i.e., it should have a > unique package structure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-6450) String.minus(String) and String.minus(Pattern) are inconsistent with List.minus(Collection).
[
https://issues.apache.org/jira/browse/GROOVY-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-6450:
--
Fix Version/s: (was: 3.x)
4.x
> String.minus(String) and String.minus(Pattern) are inconsistent with
> List.minus(Collection).
>
>
> Key: GROOVY-6450
> URL: https://issues.apache.org/jira/browse/GROOVY-6450
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 1.8.9, 2.0.8, 2.1.9, 2.2.0
> Environment: Any
>Reporter: James P. White
>Priority: Major
> Fix For: 4.x
>
> Attachments: TestGROOVY_6450.groovy
>
>
> The String.minus operations only remove the first occurrence of the equal
> elements while List.minus removes all occurrences. This is terribly
> inconsistent, as shown in these examples:
> {code}
> $ groovy -e "println ('abcabcabc' - 'b')"
> acabcabc
> $ groovy -e "println ((('abcabcabc' as List) - ('b' as List)).join())"
> acacac
> {code}
> Given my experience with trying work with multisets, I think I prefer the
> remove first/only one semantics. Given String.minus' troubled history it is
> probably less disruptive to change it yet again.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-8678) Groovy Script execution fails when comparing decimal values against decimal constant without leading 0
[
https://issues.apache.org/jira/browse/GROOVY-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8678:
--
Affects Version/s: 3.0.0-rc-3
> Groovy Script execution fails when comparing decimal values against decimal
> constant without leading 0
> --
>
> Key: GROOVY-8678
> URL: https://issues.apache.org/jira/browse/GROOVY-8678
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime, Groovysh
>Affects Versions: 2.4.x, 2.5.0, 3.0.0-rc-3
>Reporter: Dyutimoy Sarkar
>Priority: Major
> Fix For: 4.x
>
>
> Hi,
> I am reporting the following bug as I am not able to ascertain from the web
> if what I am facing is a consequence of desired intent.
> Using groovy shell to execute the following groovy script snippet fails at
> compilation phase when executing the script through java. I am using Jre1.7
> {code:java}
> public static void main(String[] args) throws Exception,
> IllegalAccessException {
> Object evaluate = new GroovyShell().evaluate("\"abcd\".length() == .34");
> System.out.println("result: " + evaluate);
> }{code}
> In the above snippet, If I replace *.34* with *0.34* then the script
> execution works as expected.
> Exception reported is as follows
> {code:java}
> Exception in thread "main"
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Script1.groovy: 1: unexpected token: . @ line 1, column 20.
> "abcd".length() == .34
> ^
> 1 error
> at
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
> at
> org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
> at
> org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
> at
> org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
> at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:332)
> at
> org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:226)
> at
> org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
> at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:230)
> at
> org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:186)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:968)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:633)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:352)
> at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:85)
> at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:321)
> at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:318)
> at
> org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:316)
> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:548)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:560)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:444)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:483)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:454)
> at groovytest.Testtest.main(Testtest.java:19)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-8678) Groovy Script execution fails when comparing decimal values against decimal constant without leading 0
[
https://issues.apache.org/jira/browse/GROOVY-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17024207#comment-17024207
]
Paul King commented on GROOVY-8678:
---
For the Parrot parser, the error message is:
{{Unexpected input: '.' at line: 1, column: 20}}
> Groovy Script execution fails when comparing decimal values against decimal
> constant without leading 0
> --
>
> Key: GROOVY-8678
> URL: https://issues.apache.org/jira/browse/GROOVY-8678
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime, Groovysh
>Affects Versions: 2.4.x, 2.5.0
>Reporter: Dyutimoy Sarkar
>Priority: Major
> Fix For: 4.x
>
>
> Hi,
> I am reporting the following bug as I am not able to ascertain from the web
> if what I am facing is a consequence of desired intent.
> Using groovy shell to execute the following groovy script snippet fails at
> compilation phase when executing the script through java. I am using Jre1.7
> {code:java}
> public static void main(String[] args) throws Exception,
> IllegalAccessException {
> Object evaluate = new GroovyShell().evaluate("\"abcd\".length() == .34");
> System.out.println("result: " + evaluate);
> }{code}
> In the above snippet, If I replace *.34* with *0.34* then the script
> execution works as expected.
> Exception reported is as follows
> {code:java}
> Exception in thread "main"
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Script1.groovy: 1: unexpected token: . @ line 1, column 20.
> "abcd".length() == .34
> ^
> 1 error
> at
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
> at
> org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
> at
> org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
> at
> org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
> at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:332)
> at
> org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:226)
> at
> org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
> at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:230)
> at
> org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:186)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:968)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:633)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:352)
> at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:85)
> at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:321)
> at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:318)
> at
> org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:316)
> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:548)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:560)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:444)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:483)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:454)
> at groovytest.Testtest.main(Testtest.java:19)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-8678) Groovy Script execution fails when comparing decimal values against decimal constant without leading 0
[
https://issues.apache.org/jira/browse/GROOVY-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8678:
--
Fix Version/s: (was: 3.x)
4.x
> Groovy Script execution fails when comparing decimal values against decimal
> constant without leading 0
> --
>
> Key: GROOVY-8678
> URL: https://issues.apache.org/jira/browse/GROOVY-8678
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime, Groovysh
>Affects Versions: 2.4.x, 2.5.0
>Reporter: Dyutimoy Sarkar
>Priority: Major
> Fix For: 4.x
>
>
> Hi,
> I am reporting the following bug as I am not able to ascertain from the web
> if what I am facing is a consequence of desired intent.
> Using groovy shell to execute the following groovy script snippet fails at
> compilation phase when executing the script through java. I am using Jre1.7
> {code:java}
> public static void main(String[] args) throws Exception,
> IllegalAccessException {
> Object evaluate = new GroovyShell().evaluate("\"abcd\".length() == .34");
> System.out.println("result: " + evaluate);
> }{code}
> In the above snippet, If I replace *.34* with *0.34* then the script
> execution works as expected.
> Exception reported is as follows
> {code:java}
> Exception in thread "main"
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Script1.groovy: 1: unexpected token: . @ line 1, column 20.
> "abcd".length() == .34
> ^
> 1 error
> at
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
> at
> org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
> at
> org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
> at
> org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
> at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:332)
> at
> org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:226)
> at
> org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
> at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:230)
> at
> org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:186)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:968)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:633)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:352)
> at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:85)
> at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:321)
> at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:318)
> at
> org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:316)
> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:548)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:560)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:444)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:483)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:454)
> at groovytest.Testtest.main(Testtest.java:19)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-8678) Groovy Script execution fails when comparing decimal values against decimal constant without leading 0
[
https://issues.apache.org/jira/browse/GROOVY-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8678:
--
Description:
Hi,
I am reporting the following bug as I am not able to ascertain from the web if
what I am facing is a consequence of desired intent.
Using groovy shell to execute the following groovy script snippet fails at
compilation phase when executing the script through java. I am using Jre1.7
{code:java}
public static void main(String[] args) throws Exception, IllegalAccessException
{
Object evaluate = new GroovyShell().evaluate("\"abcd\".length() == .34");
System.out.println("result: " + evaluate);
}{code}
In the above snippet, If I replace *.34* with *0.34* then the script execution
works as expected.
Exception reported is as follows
{code:java}
Exception in thread "main"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script1.groovy: 1: unexpected token: . @ line 1, column 20.
"abcd".length() == .34
^
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
at org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
at org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:332)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:226)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:230)
at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:186)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:968)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:633)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:352)
at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:85)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:321)
at groovy.lang.GroovyClassLoader$5.provide(GroovyClassLoader.java:318)
at
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:147)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:316)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:548)
at groovy.lang.GroovyShell.parse(GroovyShell.java:560)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:444)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:483)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:454)
at groovytest.Testtest.main(Testtest.java:19)
{code}
was:
Hi,
I am reporting the following bug as I am not able to ascertain from the web if
what I am facing is a consequence of desired intent.
Using groovy shell to execute the following groovy script snippet fails at
compilation phase when executing the script through java. I am using Jre1.7
{code:java}
public static void main(String[] args) throws Exception, IllegalAccessException
{ Object evaluate = new GroovyShell().evaluate("\"abcd\".length() == .34");
System.out.println("result: " + evaluate);
}{code}
In the above snippet, If I replace *.34* with *0.34* then the script execution
works as expected.
Exception reported is as follows
{code:java}
Exception in thread "main"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script1.groovy: 1: unexpected token: . @ line 1, column 20.
"abcd".length() == .34
^
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:311)
at
org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:151)
at org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:121)
at org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:133)
at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:332)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:226)
at
org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:192)
at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:230)
at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:186)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:968)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:633)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
at
[jira] [Updated] (GROOVY-4189) Removing a metaClass method
[
https://issues.apache.org/jira/browse/GROOVY-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-4189:
--
Fix Version/s: (was: 3.x)
4.x
> Removing a metaClass method
> ---
>
> Key: GROOVY-4189
> URL: https://issues.apache.org/jira/browse/GROOVY-4189
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Affects Versions: 1.7.2
>Reporter: Tim Yates
>Priority: Minor
> Fix For: 4.x
>
>
> Spotted a question on stackoverflow about removing a metaclass method
> The page here
> http://groovy.codehaus.org/JN3525-MetaClasses
> Says you should be able to do it by setting it to null, but we get this:
> {code}
> String.metaClass.foo = { "${delegate}foo" }
> assert 'kung'.foo() == 'kungfoo'
> String.metaClass.foo = null
> assert 'woo'.foo() == 'woofoo'
> {code}
> That last assert should fail (according to the docs), but it passes
> Is this a documentation issue?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-6518) Mop2 implementation steps
[ https://issues.apache.org/jira/browse/GROOVY-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-6518: -- Fix Version/s: (was: 3.x) 4.x > Mop2 implementation steps > - > > Key: GROOVY-6518 > URL: https://issues.apache.org/jira/browse/GROOVY-6518 > Project: Groovy > Issue Type: Task > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > Fix For: 4.x > > > Collection task to document changes for mop2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GROOVY-5360) XmlParser and XmlSlurper strip whitespace text by default
[ https://issues.apache.org/jira/browse/GROOVY-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-5360. - Assignee: Paul King Resolution: Won't Fix I propose not changing this default for the current XmlParser and XmlSlurper. We plan to look into merging those for 4.0 and we can look at the appropriate default for trimming whitespace at that time. > XmlParser and XmlSlurper strip whitespace text by default > - > > Key: GROOVY-5360 > URL: https://issues.apache.org/jira/browse/GROOVY-5360 > Project: Groovy > Issue Type: Bug > Components: XML Processing >Affects Versions: 2.0-beta-2 >Reporter: Dr. Russel Winder >Assignee: Paul King >Priority: Major > > Currently both XmlParser and XmlSlurper elide text that is only whitespace. > Surely it is for the application and not the parser to determine what to do > with whitespace that is not inside an opening or closing tag. Both classes > allow for changing the behaviour programatically. I argue that the current > default in not consistent with generally expected behaviour and so should be > changed. Clearly this is a breaking change and so should not happen in the > 1.8.x series. The 2.0.x series should take the opportunity to make this > change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-5362) XmlParser and XmlSlurper should merge
[ https://issues.apache.org/jira/browse/GROOVY-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-5362: -- Fix Version/s: (was: 3.x) 4.x > XmlParser and XmlSlurper should merge > - > > Key: GROOVY-5362 > URL: https://issues.apache.org/jira/browse/GROOVY-5362 > Project: Groovy > Issue Type: Bug > Components: XML Processing >Affects Versions: 2.0-beta-2 >Reporter: Dr. Russel Winder >Priority: Major > Fix For: 4.x > > > Currently there is XmlParser and XmlSlurper. They have essentially the same > API and yet there are some noticeable differences that should be smoothed > away. Moreover the difference between them should not be presented in terms > of different classes, but should be merged behind a virtual constructor so > that there is a single XmlParser class but different implementations with > different runtime behaviours, i.e. the strict parser and the lazy parser. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-5360) XmlParser and XmlSlurper strip whitespace text by default
[ https://issues.apache.org/jira/browse/GROOVY-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-5360: -- Fix Version/s: (was: 3.x) > XmlParser and XmlSlurper strip whitespace text by default > - > > Key: GROOVY-5360 > URL: https://issues.apache.org/jira/browse/GROOVY-5360 > Project: Groovy > Issue Type: Bug > Components: XML Processing >Affects Versions: 2.0-beta-2 >Reporter: Dr. Russel Winder >Priority: Major > > Currently both XmlParser and XmlSlurper elide text that is only whitespace. > Surely it is for the application and not the parser to determine what to do > with whitespace that is not inside an opening or closing tag. Both classes > allow for changing the behaviour programatically. I argue that the current > default in not consistent with generally expected behaviour and so should be > changed. Clearly this is a breaking change and so should not happen in the > 1.8.x series. The 2.0.x series should take the opportunity to make this > change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-4705) Compiler internals improvements collection task for Groovy 4
[ https://issues.apache.org/jira/browse/GROOVY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4705: -- Fix Version/s: (was: 3.x) 4.x > Compiler internals improvements collection task for Groovy 4 > > > Key: GROOVY-4705 > URL: https://issues.apache.org/jira/browse/GROOVY-4705 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Jochen Theodorou >Priority: Major > Fix For: 4.x > > > This is a task to collect improvements to the internal structure of the > compiler -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-4705) Compiler internals improvements collection task for Groovy 4
[ https://issues.apache.org/jira/browse/GROOVY-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4705: -- Summary: Compiler internals improvements collection task for Groovy 4 (was: Compiler internals improvements collection task for Groovy 3) > Compiler internals improvements collection task for Groovy 4 > > > Key: GROOVY-4705 > URL: https://issues.apache.org/jira/browse/GROOVY-4705 > Project: Groovy > Issue Type: Improvement > Components: Compiler >Reporter: Jochen Theodorou >Priority: Major > Fix For: 3.x > > > This is a task to collect improvements to the internal structure of the > compiler -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-4998) Real currying support
[
https://issues.apache.org/jira/browse/GROOVY-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-4998:
--
Fix Version/s: (was: 3.x)
4.x
> Real currying support
> -
>
> Key: GROOVY-4998
> URL: https://issues.apache.org/jira/browse/GROOVY-4998
> Project: Groovy
> Issue Type: New Feature
> Components: groovy-jdk
>Reporter: Kentaro Yoshida
>Priority: Major
> Fix For: 4.x
>
>
> Hi.
> Groovy's Closure have a name of method 'curry'.
> But this is not work for a real currying, it work as a partial function
> application.
> So, I wrote method of 'Real currying'.
> Referenced http://en.wikipedia.org/wiki/Currying
> {code}
> Closure add = {a, b, c -> a + b + c } // Closure of adding 3 arguments.
> assert add(1, 2, 3) == realCurry(add)(1)(2)(3)
> assert 6 == add(1, 2, 3)
> def curriedAdd = realCurry(add)
> def curriedAdd_1 = curriedAdd(1)
> def curriedAdd_1_2 = curriedAdd_1(2)
> def addResult = curriedAdd_1_2(3)
> assert 6 == addResult
> def realCurry(Closure clos) {
> if (clos.maximumNumberOfParameters >= 1) {
> return { x ->
> def cc = clos.curry(x)
> if (cc.maximumNumberOfParameters) realCurry(cc)
> else cc()
> }
> } else {
> return clos
> }
> }
> {code}
> (It's also published on gist https://gist.github.com/1193548)
> I hope this will be adopted to Groovy core.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GROOVY-4490) Method Chaining + invokeMethod
[ https://issues.apache.org/jira/browse/GROOVY-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-4490. - > Method Chaining + invokeMethod > -- > > Key: GROOVY-4490 > URL: https://issues.apache.org/jira/browse/GROOVY-4490 > Project: Groovy > Issue Type: Sub-task > Components: Compiler >Affects Versions: 1.7.4 > Environment: Using the latest groovy-eclipse version, 2.1.0 >Reporter: Mike Goodwin >Priority: Major > Fix For: 2.5.0 > > Attachments: regression1.7.1-1.7.4-2.zip, regression1.7.1-1.7.4.zip, > t.groovy > > > This bug has been introduced somewhere between 1.7.0 (the old groovy eclipse > plugin, where it worked) & 1.7.4 > I do not have a test case, but the issue seems to be with method chaining. > proxyObj.getX().getY() > What happens is getY() is run on the proxyObj. Presumably it method chaining > should work only when the return type is void, and in this case it is > confused because the return type is not as obvious. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-2756) create new user overwritable operator methods for <,==,>,<=,=>,<==>
[ https://issues.apache.org/jira/browse/GROOVY-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2756: -- Fix Version/s: (was: 3.x) 4.x > create new user overwritable operator methods for <,==,>,<=,=>,<==> > --- > > Key: GROOVY-2756 > URL: https://issues.apache.org/jira/browse/GROOVY-2756 > Project: Groovy > Issue Type: Improvement > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > Fix For: 4.x > > > as not everything we want to let <,==,>,<=,=>,<==> operate on is a total > order, it would be nice to have one of these defined only. Also the current > solution with Comparable seems to lead to many problems, because Comparable > itself is thought to be used with an exact counter part, but we might want to > let it work on other classes as well. for this we should go away from > Comparable. I would suggest we write a single method with a bitfield > containing flags for <,> and ==. Then the user can throw an exception if a > flagged operation is not available, also he can implement only < (100) or > > (010) or == (001) or <= (101) or =>(011) or <=> (111). the way to keep > backwards compatibility with this would be to add a compareTo method that > uses the bits 111.. Well needs more discussion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9003:
--
Fix Version/s: (was: 3.x)
4.x
> Allow the override of toString and equals methods for collection objects
> -
>
> Key: GROOVY-9003
> URL: https://issues.apache.org/jira/browse/GROOVY-9003
> Project: Groovy
> Issue Type: Improvement
>Reporter: paolo di tommaso
>Priority: Major
> Fix For: 4.x
>
>
> Groovy provides a nice string representation for collection objects, however
> the current behaviour do not allow custom collection classes to provide own
> string representation not to implement a custom object identity rule.
> For example:
> {code:java}
> class Mylist extends ArrayList {
> Mylist(Collection c) { super(c) }
> @Override boolean equals(Object o) { throw new
> UnsupportedOperationException () }
> @Override int hashCode() { throw new UnsupportedOperationException () }
> @Override String toString() { return 'CUSTOM STRING' }
> }
> def l = new Mylist([1,2,3])
> assert l.toString() == 'CUSTOM STRING'
> assert "$l" == '[1, 2, 3]'
> def q = new Mylist([1,2,3])
> assert l.equals(q)
> assert l == q
> {code}
> In the {{Mylist}} class the {{toString}} method is not invoked in the string
> interpolation and {{equals}} is not invoked by the {{==}} operator. This
> breaks the java polymorphism contract and create several hassles when
> implementing custom collection classes.
> I would propose to fix this behaviour in Groovy 3.0. It would be enough to
> check if the target class implements the {{toString}} and {{equals}} methods
> otherwise fallback on the current Groovy behaviour.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-3478) Patch: Automatic type promotion for numbers
[
https://issues.apache.org/jira/browse/GROOVY-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3478:
--
Summary: Patch: Automatic type promotion for numbers (was: Patch: Dynamic
type promotion)
> Patch: Automatic type promotion for numbers
> ---
>
> Key: GROOVY-3478
> URL: https://issues.apache.org/jira/browse/GROOVY-3478
> Project: Groovy
> Issue Type: Sub-task
> Components: groovy-runtime
> Environment: N/A
>Reporter: Olov Lassus
>Priority: Major
> Fix For: 4.x
>
> Attachments: groovy_dynamic_type_promotion.patch
>
>
> {noformat}
> groovy:000> 1000 * 10
> ===> 1
> {noformat}
> More info in mail thread
> http://www.nabble.com/Patch:-Dynamic-type-promotion-td22976282.html
> Patch attached. Diffstat:
> {noformat}
> main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java| 23 -
> main/org/codehaus/groovy/runtime/InvokerHelper.java | 20 -
> main/org/codehaus/groovy/runtime/typehandling/BigIntegerMath.java | 26 +
> main/org/codehaus/groovy/runtime/typehandling/IntegerMath.java| 70
> main/org/codehaus/groovy/runtime/typehandling/LongMath.java | 85
> --
> main/org/codehaus/groovy/runtime/typehandling/NumberMath.java | 90
> --
> test/groovy/operator/IntegerOperatorsTest.groovy | 141
> +-
> 7 files changed, 369 insertions(+), 86 deletions(-)
> {noformat}
> I'll also keep an updated patch available at
> http://dl.getdropbox.com/u/283098/patches/groovy_dynamic_type_promotion.patch
> Here's an overview of the patch:
> * Added test cases to IntegerOperatorsTest.groovy
> * Modified NumberMath toBigInteger and toBigDecimal methods to call into
> DefaultGroovyMethods versions
> * Modified IntegerMath to support dynamic type promotion for abs, add,
> subtract, multiply, unary minus and left shift.
> * Modified BigIntegerMath to support left shift and right shift. It does not
> support unsigned right shift (>>>).
> * Modified LongMath to support dynamic type promotion for abs, add, subtract,
> multiply, unary minus and left shift. Also changed a few "new Long" to
> "Long.valueOf" since it can be faster.
> * Modified DefaultGroovyMethods.abs to call into NumberMath. Optimized
> toBigInteger so that it doesn't do unnecessary string conversions. Tweaked a
> few comments.
> * Modified InvokerHelper.unaryMinus. Tweaked some valueOf.
> * Modified semantics for the shift operators. It's now type coerced/promoted
> the same as other binary operators. Negative shifts are not allowed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-3478) Patch: Dynamic type promotion
[
https://issues.apache.org/jira/browse/GROOVY-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3478:
--
Fix Version/s: (was: 3.x)
4.x
> Patch: Dynamic type promotion
> -
>
> Key: GROOVY-3478
> URL: https://issues.apache.org/jira/browse/GROOVY-3478
> Project: Groovy
> Issue Type: Sub-task
> Components: groovy-runtime
> Environment: N/A
>Reporter: Olov Lassus
>Priority: Major
> Fix For: 4.x
>
> Attachments: groovy_dynamic_type_promotion.patch
>
>
> {noformat}
> groovy:000> 1000 * 10
> ===> 1
> {noformat}
> More info in mail thread
> http://www.nabble.com/Patch:-Dynamic-type-promotion-td22976282.html
> Patch attached. Diffstat:
> {noformat}
> main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java| 23 -
> main/org/codehaus/groovy/runtime/InvokerHelper.java | 20 -
> main/org/codehaus/groovy/runtime/typehandling/BigIntegerMath.java | 26 +
> main/org/codehaus/groovy/runtime/typehandling/IntegerMath.java| 70
> main/org/codehaus/groovy/runtime/typehandling/LongMath.java | 85
> --
> main/org/codehaus/groovy/runtime/typehandling/NumberMath.java | 90
> --
> test/groovy/operator/IntegerOperatorsTest.groovy | 141
> +-
> 7 files changed, 369 insertions(+), 86 deletions(-)
> {noformat}
> I'll also keep an updated patch available at
> http://dl.getdropbox.com/u/283098/patches/groovy_dynamic_type_promotion.patch
> Here's an overview of the patch:
> * Added test cases to IntegerOperatorsTest.groovy
> * Modified NumberMath toBigInteger and toBigDecimal methods to call into
> DefaultGroovyMethods versions
> * Modified IntegerMath to support dynamic type promotion for abs, add,
> subtract, multiply, unary minus and left shift.
> * Modified BigIntegerMath to support left shift and right shift. It does not
> support unsigned right shift (>>>).
> * Modified LongMath to support dynamic type promotion for abs, add, subtract,
> multiply, unary minus and left shift. Also changed a few "new Long" to
> "Long.valueOf" since it can be faster.
> * Modified DefaultGroovyMethods.abs to call into NumberMath. Optimized
> toBigInteger so that it doesn't do unnecessary string conversions. Tweaked a
> few comments.
> * Modified InvokerHelper.unaryMinus. Tweaked some valueOf.
> * Modified semantics for the shift operators. It's now type coerced/promoted
> the same as other binary operators. Negative shifts are not allowed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-2147) Make DOMCategory namespace aware
[ https://issues.apache.org/jira/browse/GROOVY-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2147: -- Fix Version/s: (was: 3.x) > Make DOMCategory namespace aware > > > Key: GROOVY-2147 > URL: https://issues.apache.org/jira/browse/GROOVY-2147 > Project: Groovy > Issue Type: Improvement > Components: XML Processing > Environment: 1.0 >Reporter: Ke Zhu >Priority: Minor > > It will be more powerful to make DOMCategory associate with any namespace > just like XmlSlurper does. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-6130) weird comparison problem: rethink of single character strings into chars needed?
[ https://issues.apache.org/jira/browse/GROOVY-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-6130: -- Summary: weird comparison problem: rethink of single character strings into chars needed? (was: weird comparison problem) > weird comparison problem: rethink of single character strings into chars > needed? > > > Key: GROOVY-6130 > URL: https://issues.apache.org/jira/browse/GROOVY-6130 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.0.7 > Environment: grails 2.2.1, but happens in groovy console 2.2.1 as well >Reporter: David Marko >Priority: Major > Fix For: 4.x > > > Integer keyValue = new Integer(53) > def value = '5' > println (keyValue == value ) > result is true??? > I noticed this because a g:select tag in grails is picking incorrect choices > in the list. > ON a side note, I noticed someone is using my login of davidm and now it > shows me as David Mannicke. I registered my JIRA account back in March of > 2008, and I don't see any way to contact administrators without logging in > Can someone please either get me a new account or change this back to point > to my email address? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-6130) weird comparison problem
[ https://issues.apache.org/jira/browse/GROOVY-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-6130: -- Fix Version/s: (was: 3.x) 4.x > weird comparison problem > > > Key: GROOVY-6130 > URL: https://issues.apache.org/jira/browse/GROOVY-6130 > Project: Groovy > Issue Type: Bug > Components: groovy-runtime >Affects Versions: 2.0.7 > Environment: grails 2.2.1, but happens in groovy console 2.2.1 as well >Reporter: David Marko >Priority: Major > Fix For: 4.x > > > Integer keyValue = new Integer(53) > def value = '5' > println (keyValue == value ) > result is true??? > I noticed this because a g:select tag in grails is picking incorrect choices > in the list. > ON a side note, I noticed someone is using my login of davidm and now it > shows me as David Mannicke. I registered my JIRA account back in March of > 2008, and I don't see any way to contact administrators without logging in > Can someone please either get me a new account or change this back to point > to my email address? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-2994) String and GString do not commute under plus()
[
https://issues.apache.org/jira/browse/GROOVY-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-2994:
--
Fix Version/s: (was: 3.x)
4.x
> String and GString do not commute under plus()
> --
>
> Key: GROOVY-2994
> URL: https://issues.apache.org/jira/browse/GROOVY-2994
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 1.5.6
>Reporter: Alexander Veit
>Priority: Major
> Fix For: 4.x
>
>
> assert "${1}" + "2" instanceof GString
> assert "1" + "${2}" instanceof String
> As far as I can see plus() should be commutative throughout the GDK. At least
> it should be commutative for String and GString.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-2489) change list to array for getAt/putAt
[ https://issues.apache.org/jira/browse/GROOVY-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2489: -- Fix Version/s: 4.x > change list to array for getAt/putAt > > > Key: GROOVY-2489 > URL: https://issues.apache.org/jira/browse/GROOVY-2489 > Project: Groovy > Issue Type: Sub-task > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > Fix For: 4.x > > > if getAt and putAt are used with multiple arguments, they use a list to store > the elements. Not only does his require making a list, it also means, that in > MetaClassImpl the one of the slowest paths must be taken to select the > method. And even if we cache the method, we always have to unwrap the array. > Not to mention, that any possible static type information is lost this way. > This implementation is from a time where Groovy was not able to do vargs, but > today it is and a vargs based implementation has different advantages. For > example no rewrapping is needed, we can use use the arguments for the method > call directly. theoretically we could transport static type information this > way as well and if the implementing getAt/putAt is using a vargs based > parameter it can still get an arbitrary number of arguments. > So in the end this change would mean to keep the functionality, but change > the rules of the implementation a bit. And because the implementation has to > be changed, I consider this a breaking change -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-2488) discussion for breaking changes in Groovy 4.0
[ https://issues.apache.org/jira/browse/GROOVY-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2488: -- Fix Version/s: (was: 3.x) 4.x > discussion for breaking changes in Groovy 4.0 > - > > Key: GROOVY-2488 > URL: https://issues.apache.org/jira/browse/GROOVY-2488 > Project: Groovy > Issue Type: Task > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > Fix For: 4.x > > > Each sub task represents a discussion point for a possibly breaking change in > 2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-2488) discussion for breaking changes in Groovy 4.0
[ https://issues.apache.org/jira/browse/GROOVY-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2488: -- Summary: discussion for breaking changes in Groovy 4.0 (was: discussion for breaking changes in Groovy 3.0) > discussion for breaking changes in Groovy 4.0 > - > > Key: GROOVY-2488 > URL: https://issues.apache.org/jira/browse/GROOVY-2488 > Project: Groovy > Issue Type: Task > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > Fix For: 3.x > > > Each sub task represents a discussion point for a possibly breaking change in > 2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-3588) ClassNode:306
[
https://issues.apache.org/jira/browse/GROOVY-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3588:
--
Fix Version/s: (was: 3.x)
4.x
> ClassNode:306
> -
>
> Key: GROOVY-3588
> URL: https://issues.apache.org/jira/browse/GROOVY-3588
> Project: Groovy
> Issue Type: Sub-task
> Components: Compiler
>Reporter: Jochen Theodorou
>Priority: Major
> Fix For: 4.x
>
>
> ClassNode:306 has {code:Java}if ((modifiers & ACC_INTERFACE) == 0)
> addField("$ownClass", ACC_STATIC|ACC_PUBLIC|ACC_FINAL,
> ClassHelper.CLASS_Type, new ClassExpression(this)).setSynthetic(true);
> transformInstances = new EnumMap ASTTransformation>, Set>>(CompilePhase.class);
> for (CompilePhase phase : CompilePhase.values()) {
> transformInstances.put(phase, new HashMap ASTTransformation>, Set>());
> }{code} which should be moved somewhere else. -The "$ownclass"
> probably into verifier- (see GROOVY-3255) and the for transformInstances we
> need to find a good place. At last there is no sense in addeding these
> instances to a ClassNode, that is no primary class node. The code above is
> for example executed for each class creation in ClassHelper, which looks very
> surplus
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-4506) Groovy 4.0 code clean up (including breaking changes in the API)
[ https://issues.apache.org/jira/browse/GROOVY-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4506: -- Summary: Groovy 4.0 code clean up (including breaking changes in the API) (was: Groovy 3.0 code clean up (including breaking changes in the API)) > Groovy 4.0 code clean up (including breaking changes in the API) > > > Key: GROOVY-4506 > URL: https://issues.apache.org/jira/browse/GROOVY-4506 > Project: Groovy > Issue Type: Task > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > Fix For: 3.x > > > collection task for all the api, that should be removed or changed in 2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-4506) Groovy 4.0 code clean up (including breaking changes in the API)
[ https://issues.apache.org/jira/browse/GROOVY-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-4506: -- Fix Version/s: (was: 3.x) 4.x > Groovy 4.0 code clean up (including breaking changes in the API) > > > Key: GROOVY-4506 > URL: https://issues.apache.org/jira/browse/GROOVY-4506 > Project: Groovy > Issue Type: Task > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > Fix For: 4.x > > > collection task for all the api, that should be removed or changed in 2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-2503) MOP 2.0 design inflluencing issues
[ https://issues.apache.org/jira/browse/GROOVY-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-2503: -- Fix Version/s: (was: 3.x) 4.x > MOP 2.0 design inflluencing issues > -- > > Key: GROOVY-2503 > URL: https://issues.apache.org/jira/browse/GROOVY-2503 > Project: Groovy > Issue Type: Task > Components: groovy-runtime >Reporter: Jochen Theodorou >Priority: Major > Fix For: 4.x > > > each linked issue of this shows an issue that can't be accurately fixed > because the 1.x MOP does not allow for this. Therefor these issues will be > used as a reminder (and to be fixed) by the new MOP. I consider the MOP as > all public classes and interfaces (groovy.lang.*) used to implement the MOP > and allow the user interaction. For example if GroovyObject would need a > change, then the issue can be linked to this, if an implementation n for > example MetaClassImpl would need a change in a way that leaks not through to > the user, then it is a implementation detail and should not be linked to this -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GROOVY-2913) Closure and binding with static finals from extended classes leads to an exception.
[
https://issues.apache.org/jira/browse/GROOVY-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-2913.
-
> Closure and binding with static finals from extended classes leads to an
> exception.
> ---
>
> Key: GROOVY-2913
> URL: https://issues.apache.org/jira/browse/GROOVY-2913
> Project: Groovy
> Issue Type: Sub-task
> Components: groovy-runtime
>Affects Versions: 1.5.6, 1.6-beta-1
>Reporter: Hans Dockter
>Priority: Major
>
> The following code produces an error
> {code}
> static final String A = 'a'
> void testA() {
> def closure = {
> println A
> }
> closure()
> }
> void testC() {
> println(A)
> def closure = {
> println AbstractClass.A
> }
> closure()
> }
> class ConcreteClassTest extends AbstractClassTest {
> static final String B = 'b'
> void testB() {
> println(B)
> def closure = {
> println B
> }
> closure()
> }
> }
> {code}
> If I run ConcreteClassTest, testB and testC works fine but testA throws an
> exception.
> The stacktrace is:
> {noformat}
> groovy.lang.MissingPropertyException: No such property: A for class:
> ConcreteClass
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:49)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:59)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:169)
> at AbstractClass.getProperty(AbstractClass.groovy)
> at
> org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:172)
> at groovy.lang.Closure.getPropertyTryThese(Closure.java:200)
> at groovy.lang.Closure.getPropertyOwnerFirst(Closure.java:216)
> at groovy.lang.Closure.getProperty(Closure.java:186)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getGroovyObjectProperty(ScriptBytecodeAdapter.java:532)
> at AbstractClass$_testA_closure1.doCall(AbstractClass.groovy:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:248)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:77)
> at AbstractClass$_testA_closure1.doCall(AbstractClass.groovy)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:226)
> at
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:248)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:754)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:779)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:759)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:167)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeClosure(ScriptBytecodeAdapter.java:602)
> at AbstractClass.testA(AbstractClass.groovy:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
