[jira] [Resolved] (GROOVY-8765) Annotate generated methods with @Generated

2018-10-02 Thread Paul King (JIRA) 


 [ 
https://issues.apache.org/jira/browse/GROOVY-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King resolved GROOVY-8765.
---
   Resolution: Fixed
Fix Version/s: 2.5.3
   3.0.0-alpha-4

Thanks.

> Annotate generated methods with @Generated
> --
>
> Key: GROOVY-8765
> URL: https://issues.apache.org/jira/browse/GROOVY-8765
> Project: Groovy
>  Issue Type: New Feature
>  Components: Compiler
>Affects Versions: 3.0.0-alpha-3, 2.5.2
>Reporter: Andres Almiray
>Assignee: Andres Almiray
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> The `@Generated` annotation was added a couple of releases ago to indicate 
> that a method/class was generated by the compiler (most likely via AST 
> transformations). This annotation is already applied to methods defined by 
> `GroovyObject` however it has yet to be applied to many of the generated 
> methods added by core AST transformations.
>  
> See the following links for more context
> [https://github.com/apache/groovy/pull/617#issuecomment-336249772]
> [https://github.com/jacoco/jacoco/pull/733]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8821) groovy.bat doesn't work in Windows Docker nanoserver based containers

2018-10-02 Thread Paul King (JIRA) 


 [ 
https://issues.apache.org/jira/browse/GROOVY-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King updated GROOVY-8821:
--
Labels: contrib  (was: )

> groovy.bat doesn't work in Windows Docker nanoserver based containers
> -
>
> Key: GROOVY-8821
> URL: https://issues.apache.org/jira/browse/GROOVY-8821
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.5.2 (or 2.4.3)
> Windows 2016 host with microsoft/nanoserver based Docker container
>Reporter: Akom
>Priority: Minor
>  Labels: contrib
>
> groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in 
> Microsoft containers.  There is some logic to avoid clashing with cygwin's 
> version of find.exe (which I do have), but it doesn't cover the case of the 
> correct find.exe missing altogether.
> When running Jenkins, this is what I see:
> {noformat}
> Unpacking 
>  https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
>  to 
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest 
> on docker-003fbd390qkb2 on Windows 01
>  [00b97b92] $ 
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
>  
> c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
>  find: '/I': No such file or directory
>  find: '/C': No such file or directory
> ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
>  Please set the JAVA_HOME variable in your environment
> {noformat}
> As you can see, the error message is rather misleading. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8821) groovy.bat doesn't work in Windows Docker nanoserver based containers

2018-10-02 Thread Akom (JIRA) 


 [ 
https://issues.apache.org/jira/browse/GROOVY-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Akom updated GROOVY-8821:
-
Summary: groovy.bat doesn't work in Windows Docker nanoserver based 
containers  (was: Groovy doesn't work in Windows Docker nanoserver based 
containers)

> groovy.bat doesn't work in Windows Docker nanoserver based containers
> -
>
> Key: GROOVY-8821
> URL: https://issues.apache.org/jira/browse/GROOVY-8821
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.5.2 (or 2.4.3)
> Windows 2016 host with microsoft/nanoserver based Docker container
>Reporter: Akom
>Priority: Minor
>
> groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in 
> Microsoft containers.  There is some logic to avoid clashing with cygwin's 
> version of find.exe (which I do have), but it doesn't cover the case of the 
> correct find.exe missing altogether.
> When running Jenkins, this is what I see:
> {noformat}
> Unpacking 
>  https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
>  to 
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest 
> on docker-003fbd390qkb2 on Windows 01
>  [00b97b92] $ 
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
>  
> c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
>  find: '/I': No such file or directory
>  find: '/C': No such file or directory
> ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
>  Please set the JAVA_HOME variable in your environment
> {noformat}
> As you can see, the error message is rather misleading. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8821) Groovy doesn't work in Windows Docker nanoserver based containers

2018-10-02 Thread Akom (JIRA) 


 [ 
https://issues.apache.org/jira/browse/GROOVY-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Akom updated GROOVY-8821:
-
Description: 
groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in 
Microsoft containers.  There is some logic to avoid clashing with cygwin's 
version of find.exe (which I do have), but it doesn't cover the case of the 
correct find.exe missing altogether.

When running Jenkins, this is what I see:
{noformat}
Unpacking 
 https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
 to c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest 
on docker-003fbd390qkb2 on Windows 01
 [00b97b92] $ 
c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
 
c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
 find: '/I': No such file or directory
 find: '/C': No such file or directory
ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
 Please set the JAVA_HOME variable in your environment
{noformat}
As you can see, the error message is rather misleading. 

  was:
groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in 
Microsoft containers.  There is some logic to avoid clashing with cygwin's 
version of find.exe (which I do have), but it doesn't cover the case of the 
correct find.exe missing altogether.

When running Jenkins, this is what I see:
{noformat}
Unpacking 
 https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
 to c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest 
on docker-003fbd390qkb2 on Windows 01
 [00b97b92] $ 
c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
 
c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
 find: '/I': No such file or directory
 find: '/C': No such file or directory
ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
 Please set the JAVA_HOME variable in your environment
{noformat}
 


> Groovy doesn't work in Windows Docker nanoserver based containers
> -
>
> Key: GROOVY-8821
> URL: https://issues.apache.org/jira/browse/GROOVY-8821
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.5.2 (or 2.4.3)
> Windows 2016 host with microsoft/nanoserver based Docker container
>Reporter: Akom
>Priority: Minor
>
> groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in 
> Microsoft containers.  There is some logic to avoid clashing with cygwin's 
> version of find.exe (which I do have), but it doesn't cover the case of the 
> correct find.exe missing altogether.
> When running Jenkins, this is what I see:
> {noformat}
> Unpacking 
>  https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
>  to 
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest 
> on docker-003fbd390qkb2 on Windows 01
>  [00b97b92] $ 
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
>  
> c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
>  find: '/I': No such file or directory
>  find: '/C': No such file or directory
> ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
>  Please set the JAVA_HOME variable in your environment
> {noformat}
> As you can see, the error message is rather misleading. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GROOVY-8821) Groovy doesn't work in Windows Docker nanoserver based containers

2018-10-02 Thread Akom (JIRA) 


 [ 
https://issues.apache.org/jira/browse/GROOVY-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Akom updated GROOVY-8821:
-
Description: 
groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in 
Microsoft containers.  There is some logic to avoid clashing with cygwin's 
version of find.exe (which I do have), but it doesn't cover the case of the 
correct find.exe missing altogether.

When running Jenkins, this is what I see:
{noformat}
Unpacking 
 https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
 to c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest 
on docker-003fbd390qkb2 on Windows 01
 [00b97b92] $ 
c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
 
c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
 find: '/I': No such file or directory
 find: '/C': No such file or directory
ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
 Please set the JAVA_HOME variable in your environment
{noformat}
 

  was:
groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in 
Microsoft containers.  There is some logic to avoid clashing with cygwin's 
version of find.exe (which I do have), but it doesn't cover the case of the 
correct find.exe missing altogether.

When running Jenkins, this is what I see:
Unpacking 
[https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip]
 to c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest 
on docker-003fbd390qkb2 on Windows 01
[00b97b92] $ 
c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
 
c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
find: '/I': No such file or directory
find: '/C': No such file or directory

ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
Please set the JAVA_HOME variable in your environment


> Groovy doesn't work in Windows Docker nanoserver based containers
> -
>
> Key: GROOVY-8821
> URL: https://issues.apache.org/jira/browse/GROOVY-8821
> Project: Groovy
>  Issue Type: Bug
> Environment: Groovy 2.5.2 (or 2.4.3)
> Windows 2016 host with microsoft/nanoserver based Docker container
>Reporter: Akom
>Priority: Minor
>
> groovy.bat relies on c:\windows\system32\find.exe, which is notably absent in 
> Microsoft containers.  There is some logic to avoid clashing with cygwin's 
> version of find.exe (which I do have), but it doesn't cover the case of the 
> correct find.exe missing altogether.
> When running Jenkins, this is what I see:
> {noformat}
> Unpacking 
>  https://dl.bintray.com/groovy/maven/apache-groovy-binary-2.5.2.zip
>  to 
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest 
> on docker-003fbd390qkb2 on Windows 01
>  [00b97b92] $ 
> c:\jenkinswork\tools\hudson.plugins.groovy.GroovyInstallation\Groovy_Latest\bin\groovy.bat
>  
> c:\jenkinswork\workspace\infra\test-docker-windows-temp\00b97b92\hudson7647040981337869977.groovy
>  find: '/I': No such file or directory
>  find: '/C': No such file or directory
> ERROR: JAVA_HOME is set to an invalid directory: c:\jenkins\jdk\JDK_1.9
>  Please set the JAVA_HOME variable in your environment
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GROOVY-8727) JDK 11 Compilation Failure: ClassVisitor.visitNestMemberExperimental throws UnsupportedOperationException

2018-10-02 Thread Marc Philipp (JIRA) 


[ 
https://issues.apache.org/jira/browse/GROOVY-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16635239#comment-16635239
 ] 

Marc Philipp commented on GROOVY-8727:
--

[~paulk] [~daniel_sun] Sorry if I'm being a nag, but is there a new ETA for 
Groovy 2.5.3?

> JDK 11 Compilation Failure: ClassVisitor.visitNestMemberExperimental throws 
> UnsupportedOperationException 
> --
>
> Key: GROOVY-8727
> URL: https://issues.apache.org/jira/browse/GROOVY-8727
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 2.5.2
>Reporter: Misagh Moayyed
>Assignee: Paul King
>Priority: Major
> Fix For: 3.0.0-alpha-4, 2.5.3
>
>
> *Description:*
> Using JDK 11 and Gradle 4.9, the following compilation error is seen:
>  
> {code:java}
> > Task :core:cas-server-core-tickets:compileTestGroovy FAILED
> startup failed:
> General error during class generation: java.lang.UnsupportedOperationException
> java.lang.UnsupportedOperationException
>   at 
> groovyjarjarasm.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
>   at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:651)
>   at groovyjarjarasm.asm.ClassReader.accept(ClassReader.java:391)
>   at 
> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
>   at 
> org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
>   at 
> org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
>   at 
> org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:172)
>   at 
> org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:128)
>   at 
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClassNullable(AsmReferenceResolver.java:59)
>   at 
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveClass(AsmReferenceResolver.java:46)
>   at 
> org.codehaus.groovy.ast.decompiled.TypeSignatureParser.visitEnd(TypeSignatureParser.java:112)
>   at 
> groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:206)
>   at 
> groovyjarjarasm.asm.signature.SignatureReader.parseType(SignatureReader.java:235)
>   at 
> groovyjarjarasm.asm.signature.SignatureReader.accept(SignatureReader.java:114)
>   at 
> org.codehaus.groovy.ast.decompiled.MemberSignatureParser.createMethodNode(MemberSignatureParser.java:95)
>   at 
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.lazyInitMembers(DecompiledClassNode.java:195)
>   at 
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getMethods(DecompiledClassNode.java:103)
>   at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:399)
>   at 
> org.codehaus.groovy.classgen.AnnotationVisitor.checkIfMandatoryAnnotationValuesPassed(AnnotationVisitor.java:168)
>   at 
> org.codehaus.groovy.classgen.AnnotationVisitor.visit(AnnotationVisitor.java:80)
>   at 
> org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotation(ExtendedVerifier.java:311)
>   at 
> org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotations(ExtendedVerifier.java:157)
>   at 
> org.codehaus.groovy.classgen.ExtendedVerifier.visitConstructorOrMethod(ExtendedVerifier.java:112)
>   at 
> org.codehaus.groovy.classgen.ExtendedVerifier.visitMethod(ExtendedVerifier.java:108)
>   at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1103)
>   at 
> org.codehaus.groovy.classgen.ExtendedVerifier.visitClass(ExtendedVerifier.java:91)
>   at 
> org.codehaus.groovy.control.CompilationUnit$18.call(CompilationUnit.java:827)
>   at 
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087)
>   at 
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:631)
>   at 
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
>   at 
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
>   at 
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:565)
>   at 
> org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:179)
>   at 
> org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:57)
>   at 
> org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:77)
>   at 
> org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:65)
>   at 
>