[jira] [Commented] (GROOVY-10468) Ability to define system properties for groovyc using CompilerConfiguration

2022-02-01 Thread Paul King (Jira)


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

Paul King commented on GROOVY-10468:


For the "real life example", I found one solution on the Idea side and added 
that as a comment in the jetbrains tracker.

>From the Groovy side, we have the ability to set system properties on the 
>commandline for most of our tools (give or take the JAVA_OPTS trick often used 
>for Windows).

I was able to use a custom "spock.conf" file with the following contents:
{noformat}
// standard load commands here
property spock.iKnowWhatImDoing.disableGroovyVersionCheck=true
{noformat}
And starting Groovy with:
{noformat}
org.codehaus.groovy.tools.GroovyStarter --main groovy.ui.GroovyMain --conf 
spock.conf info/solidsoft/blog/spock2/migration/SimpleSpec.groovy
{noformat}
There is also a {{groovy.starter.conf.override}} system property that could be 
used to load such a configuration file - which is fine for Groovy, but going 
back to the Idea scenario, if you could set that property you could set the 
spock one directly.

With respect to {{CompilerConfiguration}} the class, it is stateful and 
different instances can have different values and happily work in parallel. 
System properties are a shared resource, so I wonder if trying to associate 
such properties with that class is the way to go?

I was thinking that perhaps we extend the configscript DSL to support setting 
such properties but I think that is already supported. I just tried having a 
config script:

{code:groovy}
System.setProperty('spock.iKnowWhatImDoing.disableGroovyVersionCheck', 'true')
{code}

And calling that with {{--configscript}} seems to achieve the desired outcome.


> Ability to define system properties for groovyc using CompilerConfiguration
> ---
>
> Key: GROOVY-10468
> URL: https://issues.apache.org/jira/browse/GROOVY-10468
> Project: Groovy
>  Issue Type: New Feature
>  Components: Compiler
>Affects Versions: 3.0.9, 4.0.0
>Reporter: Marcin Zajaczkowski
>Priority: Minor
>
> In some cases, it would be useful to be able to define system properties for 
> groovyc using CompilerConfiguration.
> The real life example is a limitation of Idea which doesn't allow to provide 
> system properties for groovyc (just for javac) - 
> [https://youtrack.jetbrains.com/issue/IDEA-287642] . As a result, Spock 
> 2.0-groovy-3.0 cannot be easily compiled in Idea if Maven project is imported.
> There are probably also some other situations where CompilerConfiguration 
> might be more handy than playing with Gradle/Maven/Ant/Netbeans 
> configurations.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (GROOVY-10466) Compilation error on Spock expectation

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles commented on GROOVY-10466:
--

Just some general info for any present or future readers:

These are all errors for the "no more interactions" expression at the end of a 
spock test case: "0 * _"

It is described here for reference: 
https://spockframework.org/spock/docs/1.0/interaction_based_testing.html

Not sure if spock requires a change to make this work.  The Groovy 4 support PR 
is here: https://github.com/spockframework/spock/pull/1382

> Compilation error on Spock expectation
> --
>
> Key: GROOVY-10466
> URL: https://issues.apache.org/jira/browse/GROOVY-10466
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 4.0.0-beta-2, 4.0.0-rc-1, 4.0.0-rc-2, 4.0.0
>Reporter: Lóránt Pintér
>Priority: Major
>
> *Reproduction steps*
>  * Check out [https://github.com/gradle/gradle/tree/lptr/groovy-4-bugs]
>  * Run {{./gradlew :execution:compileAll}}, it works using 4.0.0-beta-1!
>  * Change the Groovy version here to `4.0.0-beta-2`: 
> [https://github.com/gradle/gradle/blob/860e74522dcbf2df635a27f38fef1daa0b093322/build-logic/dependency-modules/src/main/kotlin/gradlebuild/modules/extension/ExternalModulesExtension.kt#L23]
>  * Run {{./gradlew :execution:compileAll}}
> It fails with:
> {code:java}
> :execution:compileTestGroovy FAILED   
> Executing Spock 2.0.0-groovy-3.0 with NOT compatible Groovy version 
> 4.0.0-beta-2 due to set spock.iKnowWhatImDoing.disableGroovyVersionCheck 
> system property. This is unsupported and may result in weird runtime errors!  
>
> startup failed:   
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BroadcastChangingOutputsStepTest.groovy:
>  60: Interaction is missing a target @ line 60, column 13. 
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BuildCacheStepTest.groovy:
>  94: Interaction is missing a target @ line 94, column 13.   
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BuildCacheStepTest.groovy:
>  117: Interaction is missing a target @ line 117, column 13. 
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BuildCacheStepTest.groovy:
>  146: Interaction is missing a target @ line 146, column 13. 
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BuildCacheStepTest.groovy:
>  170: Interaction is missing a target @ line 170, column 13. 
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BuildCacheStepTest.groovy:
>  193: Interaction is missing a target @ line 193, column 13. 
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BuildCacheStepTest.groovy:
>  214: Interaction is missing a target @ line 214, column 13. 
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BuildCacheStepTest.groovy:
>  239: Interaction is missing a target @ line 239, column 13. 
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/BuildCacheStepTest.groovy:
>  251: Interaction is missing a target @ line 251, column 13. 
>0 * _  
>^  
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/CancelExecutionStepTest.groovy:
>  37: Interaction is missing a target @ line 37, column 12.  
>0 *_   
>   ^   
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/CancelExecutionStepTest.groovy:
>  53: Interaction is missing a target @ line 53, column 12.  
>0 *_   
>   ^   
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/execution/src/test/groovy/org/gradle/internal/execution/steps/CancelExecutionStepTest.groovy:
>  70: Interaction is missing a target @ line 70, column 12. 

[jira] [Commented] (GROOVY-10467) Compilation fails with method detected as transient

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles commented on GROOVY-10467:
--

https://github.com/apache/groovy/pull/1680

> Compilation fails with method detected as transient
> ---
>
> Key: GROOVY-10467
> URL: https://issues.apache.org/jira/browse/GROOVY-10467
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 4.0.0-beta-2, 4.0.0-rc-1, 4.0.0-rc-2, 4.0.0
>Reporter: Lóránt Pintér
>Assignee: Eric Milles
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> *Reproduction steps*
>  * Check out [https://github.com/gradle/gradle/tree/lptr/groovy-4-bugs]
>  * Run {{./gradlew :ivy:compileAll}}, it works using 4.0.0-beta-1!
>  * Change the Groovy version here to `4.0.0-beta-2`: 
> [https://github.com/gradle/gradle/blob/860e74522dcbf2df635a27f38fef1daa0b093322/build-logic/dependency-modules/src/main/kotlin/gradlebuild/modules/extension/ExternalModulesExtension.kt#L23]
>  * Run {{./gradlew :ivy:compileAll}}
> It fails with:
> {code:java}
> :ivy:compileTestFixturesGroovy FAILED 
> Groovy compilation avoidance is an incubating feature.
> Executing Spock 2.0.0-groovy-3.0 with NOT compatible Groovy version 
> 4.0.0-beta-2 due to set spock.iKnowWhatImDoing.disableGroovyVersionCheck 
> system property. This is unsupported and may result in weird runtime errors!  
>
> startup failed:   
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/ivy/src/testFixtures/groovy/org/gradle/api/publish/ivy/AbstractIvyPublishIntegTest.groovy:
>  -1: The method 'void expectFiles(java.lang.String[])' has an incorrect 
> modifier transient.
>  @ line -1, column -1.
> 1 error
> {code}
> Build scan: 
> [https://ge.gradle.org/s/phu26h5udswba/console-log?task=:ivy:compileTestFixturesGroovy]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[GitHub] [groovy] eric-milles opened a new pull request #1680: GROOVY-10467: trait: clear transient modifier from helper method

2022-02-01 Thread GitBox


eric-milles opened a new pull request #1680:
URL: https://github.com/apache/groovy/pull/1680


   In the case of a binary trait, a helper method may have the varargs modifier 
(same as transient for a field).  This change removes that before the transient 
modifier check that was added in Groovy 4 (GROOVY-10140).  I'm concerned this 
may be an issue elsewhere.  It may be possible to clear the modifier in the 
class decompiler; not sure if the modifier is important to the Groovy model.
   
   https://issues.apache.org/jira/browse/GROOVY-10467
   https://issues.apache.org/jira/browse/GROOVY-10140


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

To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[jira] [Assigned] (GROOVY-10467) Compilation fails with method detected as transient

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles reassigned GROOVY-10467:


Assignee: Eric Milles

> Compilation fails with method detected as transient
> ---
>
> Key: GROOVY-10467
> URL: https://issues.apache.org/jira/browse/GROOVY-10467
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 4.0.0-beta-2, 4.0.0-rc-1, 4.0.0-rc-2, 4.0.0
>Reporter: Lóránt Pintér
>Assignee: Eric Milles
>Priority: Major
>
> *Reproduction steps*
>  * Check out [https://github.com/gradle/gradle/tree/lptr/groovy-4-bugs]
>  * Run {{./gradlew :ivy:compileAll}}, it works using 4.0.0-beta-1!
>  * Change the Groovy version here to `4.0.0-beta-2`: 
> [https://github.com/gradle/gradle/blob/860e74522dcbf2df635a27f38fef1daa0b093322/build-logic/dependency-modules/src/main/kotlin/gradlebuild/modules/extension/ExternalModulesExtension.kt#L23]
>  * Run {{./gradlew :ivy:compileAll}}
> It fails with:
> {code:java}
> :ivy:compileTestFixturesGroovy FAILED 
> Groovy compilation avoidance is an incubating feature.
> Executing Spock 2.0.0-groovy-3.0 with NOT compatible Groovy version 
> 4.0.0-beta-2 due to set spock.iKnowWhatImDoing.disableGroovyVersionCheck 
> system property. This is unsupported and may result in weird runtime errors!  
>
> startup failed:   
> /Users/lptr/Workspace/gradle/gradle-groovy-4/subprojects/ivy/src/testFixtures/groovy/org/gradle/api/publish/ivy/AbstractIvyPublishIntegTest.groovy:
>  -1: The method 'void expectFiles(java.lang.String[])' has an incorrect 
> modifier transient.
>  @ line -1, column -1.
> 1 error
> {code}
> Build scan: 
> [https://ge.gradle.org/s/phu26h5udswba/console-log?task=:ivy:compileTestFixturesGroovy]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10312) MissingMethodException in method with default parameter in trait - regression in 3.0.9

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10312:
-
Fix Version/s: 2.5.16

> MissingMethodException in method with default parameter in trait - regression 
> in 3.0.9
> --
>
> Key: GROOVY-10312
> URL: https://issues.apache.org/jira/browse/GROOVY-10312
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 4.0.0-beta-1, 3.0.9
>Reporter: Marcin Zajaczkowski
>Assignee: Eric Milles
>Priority: Minor
>  Labels: trait, traits
> Fix For: 4.0.0-beta-2, 2.5.16, 3.0.10
>
>
> After switch from 3.0.8 to 3.0.9 Groovy throws at runtime 
> MissingMethodException for static method in a trait called from another 
> trait, but only if a given method has a default parameter.
> A stripped down code to reproduce problem:
> {code:java}
> class StaticStaticInTraitProblem implements TLevel1 {
> static void main(String[] args) {
> staticMethodWithDefaultParameter()
> }
> }
> trait TLevel1 extends TLevel2 {
> static void staticMethodWithDefaultParameter(String params = "") { 
> //default param is required to make it fail at runtime
> static2() //fails with MissingMethodException: No signature of 
> method: static foobar.TLevel1.static2() is applicable ...
> }
> }
> trait TLevel2 {
> static void static2() {}
> }{code}
> A stacktrace:
> {code:java}
> Exception in thread "main" groovy.lang.MissingMethodException: No signature 
> of method: static foobar.TLevel1.static2() is applicable for argument types: 
> () values: []
> Possible solutions: wait(), wait(long), split(groovy.lang.Closure), 
> wait(long, int), notify(), stream()
> at 
> groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1584)
> at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1570)
> at 
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:1003)
> at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:180)
> at 
> foobar.TLevel1$Trait$Helper.$static_methodMissing(StaticStaticInTraitProblem2Spec.groovy)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
> at 
> groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1582)
> at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1570)
> at 
> org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:50)
> at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
> at 
> foobar.TLevel1$Trait$Helper.staticMethodWithDefaultParameter(StaticStaticInTraitProblem2Spec.groovy:11)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
> at 
> org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.invoke(StaticMetaMethodSite.java:44)
> at 
> org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
> at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
> at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
> at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:240)
> at 
> foobar.TLevel1$Trait$Helper.staticMethodWithDefaultParameter(StaticStaticInTraitProblem2Spec.groovy)
> at 
> foobar.TLevel1$Trait$Helper$staticMethodWithDefaultParameter.call(Unknown 
> Source)
> at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at 
> 

[jira] [Updated] (GROOVY-10197) java.lang.VerifyError using property inside enum's constant

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10197:
-
Fix Version/s: 2.5.16

> java.lang.VerifyError using property inside enum's constant
> ---
>
> Key: GROOVY-10197
> URL: https://issues.apache.org/jira/browse/GROOVY-10197
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 3.0.8
>Reporter: Ivan Kuznetsov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.9, 2.5.16
>
>
> I'm facing with this strange error after script compiles successfully but 
> fails to load using groovy 3.0.8:
> {noformat}
> java.lang.VerifyError: Bad type on operand stack
> Exception Details:
>   Location:
> E$1.(Ljava/lang/String;ILjava/util/LinkedHashMap;)V @50: 
> invokevirtual
>   Reason:
> Type 'E$1' (current frame, stack[0]) is not assignable to 
> 'groovy/lang/Closure'
>   Current Frame:
> bci: @50
> flags: { }
> locals: { 'E$1', 'java/lang/String', integer, 'java/util/LinkedHashMap', 
> integer }
> stack: { 'E$1' }
>   Bytecode:
> 000: 2a2b 1c2d 01b7 0012 0436 0415 042a 5fb5
> 010: 0014 1504 572d c700 0704 a700 0403 9900
> 020: 13bb 0016 5912 18b7 001b c000 1dbf 
> 030: bf2a b600 23c0 0004 c000 2512 26b6 002a
> 040: 9900 1a2d 1226 b900 3002 003a 0519 05b8
> 050: 0036 2a5f b500 1419 0557 2a2d b800 3c01
> 060: 57b1   
>   Stackmap Table:
> full_frame(@29,{Object[#2],Object[#69],Integer,Object[#37],Integer},{})
> same_locals_1_stack_item_frame(@30,Integer)
> full_frame(@46,{},{Object[#29]})
> full_frame(@49,{Object[#2],Object[#69],Integer,Object[#37],Integer},{})
> same_frame(@90)
> same_frame(@97)   at E.(ideaGroovyConsole.groovy)
>   at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native 
> Method)
>   at 
> java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1155)
>   at 
> java.base/jdk.internal.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:42)
>   at 
> java.base/jdk.internal.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:186)
>   at 
> java.base/java.lang.reflect.Field.acquireFieldAccessor(Field.java:1126)
>   at java.base/java.lang.reflect.Field.getFieldAccessor(Field.java:1107)
>   at java.base/java.lang.reflect.Field.get(Field.java:419)
>   at 
> org.codehaus.groovy.reflection.CachedField.getProperty(CachedField.java:68)
>   at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1900)
>   at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3874)
>   at 
> org.codehaus.groovy.runtime.callsite.ClassMetaClassGetPropertySite.getProperty(ClassMetaClassGetPropertySite.java:50)
>   at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
>   at ideaGroovyConsole.run(ideaGroovyConsole.groovy:110) {noformat}
> Here is the reproducing script:
> {code:java}
> @CompileStatic
> enum E {
> E1{
> //int value = 1
> int getValue() { 1 }
> }
> int getValue() { -1 }
> }
> {code}
> If you use an overriding method, all is working fine. But replacing method 
> with local field causes an error above. I think it is 
> {{@CompileStatic}}-specific error, because without this annotation both 
> versions are loaded successfully.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10179) STC: instanceof and for-in variable type

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10179:
-
Fix Version/s: 2.5.16

> STC: instanceof and for-in variable type
> 
>
> Key: GROOVY-10179
> URL: https://issues.apache.org/jira/browse/GROOVY-10179
> Project: Groovy
>  Issue Type: Bug
>  Components: Static Type Checker
>Affects Versions: 2.5.14, 3.0.8, 4.0.0-alpha-3
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.16
>
>
> Variation of GROOVY-6240.  Consider the following:
> {code:groovy}
> @groovy.transform.TypeChecked
> void test(args) {
>   if (args instanceof Map) {
> for (e in args) {
>   print "$e.key $e.value" // STC errors: No such property "key/value" for 
> Object
> }
>   }
> }
> test(a:1,b:2,c:3.14)
> {code}
> When the extra layer of the instanceof check is added, STC does not use Map 
> type when inferring type of for-in variable "e".



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10199) ASTTest cannot reference types from transform classpath

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10199:
-
Fix Version/s: 2.5.16

> ASTTest cannot reference types from transform classpath
> ---
>
> Key: GROOVY-10199
> URL: https://issues.apache.org/jira/browse/GROOVY-10199
> Project: Groovy
>  Issue Type: Bug
>  Components: xforms
>Affects Versions: 2.5.14, 3.0.8, 4.0.0-alpha-3
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.16
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class C {
>   void test() {
> @groovy.transform.ASTTest(value={
>   org.apache.commons.lang3.tuple.Pair.of(node,null)
> })
> def var = null
>   }
> }
> {code}
> With {{commons-lang3.jar}} on the compiler classpath, this code emits error 
> "Cannot get property 'apache' on null object".



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10191) NoSuchMethodError during static field inlining is not caught, unlike NoSuchFieldException

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10191:
-
Fix Version/s: 2.5.16

> NoSuchMethodError during static field inlining is not caught, unlike 
> NoSuchFieldException
> -
>
> Key: GROOVY-10191
> URL: https://issues.apache.org/jira/browse/GROOVY-10191
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 2.5.14, 3.0.8, 4.0.0-alpha-3
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.16
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This is a bit hard to reproduce.  We have a situation something like this:
> {code:groovy}
> class Main {
>   private static final x = Type.CONST
> }
> {code}
> Then, this is defined in a separate project or jar:
> {code:groovy}
> class Type {
>   public static final CONST = 'value'
>   static {
> // some other class initialization that is failing due to classpath 
> ordering
>   }
> }
> {code}
> When {{Verifier}} tries to inline the initial value for {{x}}, 
> {{ExpressionUtils}} falls into the non-primary type path ({{Type}} is in 
> separate project or jar).  We had a situation where we had two versions of a 
> 3rd-party library on the classpath and it ended up throwing 
> {{NoSuchMethodError}} when the lower version was picked up.  This can be 
> simulated by adding {{throw new NoSuchMethodError()}} to the static 
> initializer of {{Type}}.
> https://github.com/apache/groovy/blob/d7684d101d64ca6da28fdb8069ea92475d011168/src/main/java/org/apache/groovy/ast/tools/ExpressionUtils.java#L236



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10164) RootLoader cannot be set as system class loader in Java 12+

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10164:
-
Fix Version/s: 2.5.16

> RootLoader cannot be set as system class loader in Java 12+
> ---
>
> Key: GROOVY-10164
> URL: https://issues.apache.org/jira/browse/GROOVY-10164
> Project: Groovy
>  Issue Type: Bug
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.16
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Support for 
> {{-Djava.system.class.loader=org.codehaus.groovy.tools.RootLoader}} is 
> missing for Java 12+.  The constructor that accepts {{ClassLoader}} is 
> private.  See code excerpt below that tries to call this constructor using 
> reflection.
> java.lang.ClassLoader
> {code:java}
> static synchronized ClassLoader initSystemClassLoader() {
> // ...
> String cn = System.getProperty("java.system.class.loader");
> if (cn != null) {
> try {
> // custom class loader is only supported to be loaded from 
> unnamed module
> Constructor ctor = Class.forName(cn, false, builtinLoader)
>
> .getDeclaredConstructor(ClassLoader.class);
> scl = (ClassLoader) ctor.newInstance(builtinLoader);
> {code}
> {code}
> java.lang.Error: class java.lang.ClassLoader (in module java.base) cannot 
> access a member of class org.codehaus.groovy.tools.RootLoader with modifiers 
> "private"
>   at 
> java.lang.ClassLoader.initSystemClassLoader(java.base@12.0.2/ClassLoader.java:1989)
>   at java.lang.System.initPhase3(java.base@12.0.2/System.java:2132)
> Caused by: java.lang.IllegalAccessException: class java.lang.ClassLoader (in 
> module java.base) cannot access a member of class 
> org.codehaus.groovy.tools.RootLoader with modifiers "private"
>   at 
> jdk.internal.reflect.Reflection.newIllegalAccessException(java.base@12.0.2/Reflection.java:376)
>   at 
> java.lang.reflect.AccessibleObject.checkAccess(java.base@12.0.2/AccessibleObject.java:639)
>   at 
> java.lang.reflect.Constructor.newInstanceWithCaller(java.base@12.0.2/Constructor.java:490)
>   at 
> java.lang.reflect.Constructor.newInstance(java.base@12.0.2/Constructor.java:481)
>   at 
> java.lang.ClassLoader.initSystemClassLoader(java.base@12.0.2/ClassLoader.java:1977)
>   at java.lang.System.initPhase3(java.base@12.0.2/System.java:2132)
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10141) NPE in InnerClassVisitor for non-static inner class CCE within two AICs

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10141:
-
Fix Version/s: 2.5.16

> NPE in InnerClassVisitor for non-static inner class CCE within two AICs
> ---
>
> Key: GROOVY-10141
> URL: https://issues.apache.org/jira/browse/GROOVY-10141
> Project: Groovy
>  Issue Type: Bug
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.16
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> class Outer {
> class Inner {
> }
> def obj = new Object() {
> String toString() {
> new Object() {
> String toString() {
> new Inner()
> }
> }
> }
> }
> }
> {code}
> https://github.com/groovy/groovy-eclipse/issues/1268
> {code}
> java.lang.NullPointerException
> at 
> org.codehaus.groovy.classgen.InnerClassVisitor.insertThis0ToSuperCall(InnerClassVisitor.java:306)
> at 
> org.codehaus.groovy.classgen.InnerClassVisitor.passThisReference(InnerClassVisitor.java:286)
> at 
> org.codehaus.groovy.classgen.InnerClassVisitor.visitConstructorCallExpression(InnerClassVisitor.java:147)
> at 
> org.codehaus.groovy.ast.expr.ConstructorCallExpression.visit(ConstructorCallExpression.java:45)
> at 
> org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:117)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:200)
> at 
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:41)
> at 
> org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
> at 
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:70)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:138)
> at 
> org.codehaus.groovy.classgen.InnerClassVisitor.visitConstructorOrMethod(InnerClassVisitor.java:116)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:106)
> at org.codehaus.groovy.ast.ClassNode.visitMethods(ClassNode.java:1110)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1103)
> at 
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:52)
> at 
> org.codehaus.groovy.classgen.InnerClassVisitor.visitClass(InnerClassVisitor.java:86)
> at 
> org.codehaus.groovy.control.CompilationUnit.lambda$addPhaseOperations$4(CompilationUnit.java:213)
> at 
> org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:928)
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10112) IndexedProperty AST transform should only provide the getter for immutable fields

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10112:
-
Fix Version/s: 2.5.16

> IndexedProperty AST transform should only provide the getter for immutable 
> fields
> -
>
> Key: GROOVY-10112
> URL: https://issues.apache.org/jira/browse/GROOVY-10112
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Paul King
>Assignee: Paul King
>Priority: Major
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.16
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10106) STC error for call to static trait method from closure

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10106:
-
Fix Version/s: 2.5.16

> STC error for call to static trait method from closure
> --
>
> Key: GROOVY-10106
> URL: https://issues.apache.org/jira/browse/GROOVY-10106
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.5.14
>Reporter: Renato Athaydes
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-1, 3.0.9, 2.5.16
>
>
> The following code fails to compile:
> {code:groovy}
> class Foo {
> String bar
> }
> @groovy.transformn.CompileStatic
> trait A {
> final Foo foo = new Foo().with {
> config(it)
> it
> }
> static void config(foo) {
> foo.bar = 'bar'
> }
> }
> class C implements A {
> }
> print new C().foo.bar
> {code}
>  
> The error is:
> {code}
> src/test/groovy/bar/Foo.groovy: 14: [Static type checking] - Cannot find 
> matching method bar.A#config(bar.Foo). Please check if the declared type is 
> correct and if the method exists.
>  @ line 14, column 9.
>config(it)
>^
> 1 error
> {code}
>  
> If I change {{trait}} to {{class}}, it compiles successfully.
> I think this has to do with the fact that trait cannot have constructors, and 
> hence the context in which the code executes does not have the right imports?
> Anyway, this was working fine before we upgraded to the latest Groovy 2.5.x 
> version from 2.4.x.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10037) Private setter method in class that is extended by another class cannot be found.

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10037:
-
Fix Version/s: 2.5.16

> Private setter method in class that is extended by another class cannot be 
> found.
> -
>
> Key: GROOVY-10037
> URL: https://issues.apache.org/jira/browse/GROOVY-10037
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 3.0.7
> Environment: groovy 3.0.7
> javac 13.0.2
> Windows/10
>Reporter: Eric Holley
>Assignee: Eric Milles
>Priority: Major
> Fix For: 3.0.8, 2.5.16
>
> Attachments: StaticSetterBug.groovy, StaticSetterBug.groovy
>
>
> If you have a class that is extended by another class and there is a private 
> setter in the class that is extended, that setter cannot be found at runtime. 
> Example script attached. At runtime, the following exception trace is shown:
> {code:java}
> groovy.lang.MissingPropertyException: No such property: $priv for class: 
> com.my_example.ExtendedBugClass
> Possible solutions: $pub
> at com.my_example.BugClass.test(StaticSetterBug.groovy:27)
> at com.my_example.ExtendedBugClass.run(StaticSetterBug.groovy:37)
> at com.my_example.ExtendedBugClass$run.call(Unknown Source)
> at com.my_example.StaticSetterBug.run(StaticSetterBug.groovy:42)
> at jdk.internal.reflect.GeneratedMethodAccessor305.invoke(Unknown Source)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>  Note: Problem occurs regardless of whether classes are dynamic or static 
> compiled. The '$' in the names has no effect, a letter in its place has same 
> problem. The extending class does not have this problem. A stand alone class 
> also does not have this problem. If the setter is public or protected, the 
> problem goes away. Private getters do not display the problem.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-10027) STC: NamedParams error for method call argument

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10027:
-
Fix Version/s: 2.5.16

> STC: NamedParams error for method call argument
> ---
>
> Key: GROOVY-10027
> URL: https://issues.apache.org/jira/browse/GROOVY-10027
> Project: Groovy
>  Issue Type: Bug
>  Components: Static Type Checker
>Affects Versions: 2.5.14, 3.0.7, 4.0.0-alpha-2
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-alpha-3, 3.0.9, 2.5.16
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Consider the following:
> {code:groovy}
> import groovy.transform.NamedParam
> import groovy.transform.NamedParams
> @groovy.transform.TypeChecked
> //@Configuration
> class Config {
>   //@Value
>   String indexName
>   //@Bean
>   ResultType resultType() {  }
>   //@Bean
>   def facetApplier() { new FacetApplier(index:indexName, 
> resultType:resultType()) }
> }
> //@Component
> class FacetApplier {
> protected final String index
> protected final ResultType resultType
> FacetApplier(@NamedParams([
> @NamedParam(value='index', type=String, required=true),
> @NamedParam(value='resultType', type=ResultType, required=true)]) Map 
> props)
> {
> this.index = props.index
> this.resultType = props.resultType
> }
> }
> class ResultType {
> }
> {code}
> Constructor call expression "new FacetApplier(index:indexName, 
> resultType:resultType())" has static type checking error for "resultType" 
> named parameter.  {{[Static type checking] - parameter for named arg 
> 'resultType' has type 'java.lang.Object' but expected 'ResultType'.}}
> If {{resultType()}} is cast or replaced with a variable, the error goes away.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-9807) Static compile of dynamically generated code produces different output in a top-level class and a nested class

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-9807:

Fix Version/s: 2.5.16

> Static compile of dynamically generated code produces different output in a 
> top-level class and a nested class
> --
>
> Key: GROOVY-9807
> URL: https://issues.apache.org/jira/browse/GROOVY-9807
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 3.0.6
> Environment: openjdk version "1.8.0_242"
> OpenJDK Runtime Environment (build 1.8.0_242-8u242-b08-0ubuntu3~18.04-b08)
> OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
>Reporter: Lyuben Atanasov
>Assignee: Eric Milles
>Priority: Critical
> Fix For: 4.0.0-alpha-3, 2.5.16, 3.0.10
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I have encountered an issue when trying to generate code, containing chained 
> method calls, at runtime (without source code) and compiling using 
> CompileStatic.
> What I am trying to achieve is produce code similar to:
> {code:java}
> public StringBuilder test() {
> StringBuilder sb = new StringBuilder().append("testString");
> return sb;
> }
> {code}
> I create the appropriate AST nodes, statements, expressions, etc.
> Everything works fine if I add a method like the one shown in a top-level 
> class (the class is also dynamically generated at runtime). However, if I try 
> to add the exact same method to a nested class, it seems like the groovy 
> compiler gets somehow confused and, judging by the decompiler output, 
> produces something like:
> {code:java}
> public StringBuilder test() {
> StringBuilder sb = 
> ((StringBuilder)((Closure)this).getThisObject()).append("testString");
> return sb;
> }
> {code}
> Naturally, this does not work.
> Here's how I try to generate the method:
> {code:java}
> ClassNode topLevelClass = ClassHelper.make(
> "com.example.groovycompiler.test.TopLevelClass");
> InnerClassNode nestedClass = new InnerClassNode(
> topLevelClass,
> "com.example.groovycompiler.test.TopLevelClass$NestedClass",
> Opcodes.ACC_PUBLIC | Opcodes.ACC_STATIC,
> ClassHelper.OBJECT_TYPE);
> ClassNode stringBuilderClass = ClassHelper.make(StringBuilder.class);
> nestedClass.addMethod(
> "test",
> Opcodes.ACC_PUBLIC,
> stringBuilderClass,
> Parameter.EMPTY_ARRAY,
> ClassNode.EMPTY_ARRAY,
> block(
> declS(
> varX("sb", stringBuilderClass),
> callX(ctorX(stringBuilderClass), "append",
> args(constX("testString",
> returnS(
> varX("sb", stringBuilderClass))
> )
> );
> {code}
> Perhaps I am missing something, in which case I will be very happy to receive 
> some pointers.
> I have created a github repo with a maven project containing a unit test that 
> demonstrates the issue: 
> https://github.com/l-atanasov/groovy-static-compile-issue
> Note, that I have extended the CompilationUnit a little to allow to run the 
> static compiler without source.
> Also, if I am not using the static compiler, everything works as expected.
> Update: reformatted code for readability



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (GROOVY-9386) Field initialized in a trait using tap doesn't work correctly

2022-02-01 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-9386:

Fix Version/s: 2.5.16

> Field initialized in a trait using tap doesn't work correctly
> -
>
> Key: GROOVY-9386
> URL: https://issues.apache.org/jira/browse/GROOVY-9386
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.5.9, 3.0.0-rc-3
>Reporter: Matthias Kiefer
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.0.0-alpha-1, 3.0.6, 2.5.16
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The following code
> {code:groovy}
> class Foo {
> int bar
> }
> trait TestTrait {
> def foo = new Foo().tap{
> bar = 1
> }
> }
> class SomeClass implements TestTrait {
> }
> new SomeClass()
> {code}
> fails with the following error:
> {noformat}
> Caught: groovy.lang.MissingPropertyException: No such property: bar for 
> class: SomeClass
> Possible solutions: foo
> groovy.lang.MissingPropertyException: No such property: bar for class: 
> SomeClass
> Possible solutions: foo
>   at TestTrait$Trait$Helper$__init__closure1.doCall(scratch.groovy:8)
>   at TestTrait$Trait$Helper.$init$(scratch.groovy:7)
>   at SomeClass.(scratch.groovy)
>   at scratch.run(scratch.groovy:16)
> {noformat}
> if using the following code in the tap makes it work correctly:
> {code:groovy}
> trait TestTrait {
> def foo = new Foo().tap{
> it.bar = 1
> }
> }
> {code}
> Also when used in a class directly, it works also correctly:
> {code:groovy}
> class SomeClass {
> def foo = new Foo().tap{
> bar = 1
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Comment Edited] (GROOVY-10469) Groovy 4.0.0 BSF module does not have a release version in central Maven repository

2022-02-01 Thread Alexander Veit (Jira)


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

Alexander Veit edited comment on GROOVY-10469 at 2/1/22, 12:47 PM:
---

OK, didn't hear about it, and the release notes say nothing about it. BTW, 
personally I'm fine with it, and I don't think that our customers actually have 
use cases for BSF.

So I think this issue could be closed.


was (Author: veita):
OK, didn't hear about it, and the release notes say nothing about it. BTW, 
personally I'm fine with it, and I don't think that our customers actually have 
use cases for BSF.

> Groovy 4.0.0 BSF module does not have a release version in central Maven 
> repository
> ---
>
> Key: GROOVY-10469
> URL: https://issues.apache.org/jira/browse/GROOVY-10469
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-bsf
>Affects Versions: 4.0.0
>Reporter: Alexander Veit
>Priority: Major
>
> The 4.0.0 version is missing.
> See https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-bsf/



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (GROOVY-10469) Groovy 4.0.0 BSF module does not have a release version in central Maven repository

2022-02-01 Thread Alexander Veit (Jira)


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

Alexander Veit commented on GROOVY-10469:
-

OK, didn't hear about it, and the release notes say nothing about it. BTW, 
personally I'm fine with it, and I don't think that our customers actually have 
use cases for BSF.

> Groovy 4.0.0 BSF module does not have a release version in central Maven 
> repository
> ---
>
> Key: GROOVY-10469
> URL: https://issues.apache.org/jira/browse/GROOVY-10469
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-bsf
>Affects Versions: 4.0.0
>Reporter: Alexander Veit
>Priority: Major
>
> The 4.0.0 version is missing.
> See https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-bsf/



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (GROOVY-10469) Groovy 4.0.0 BSF module does not have a release version in central Maven repository

2022-02-01 Thread Paul King (Jira)


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

Paul King commented on GROOVY-10469:


We dropped that module. We asked on the dev and users lists:

https://lists.apache.org/thread/6xxhyq2hfqkyjkhyklj1tpm5bxd34r5l

We also did a twitter poll:

https://twitter.com/paulk_asert/status/1379672434131881985

We had 0% of users wanting to keep it - most folks wanting multiple language 
scripting seem to be using JSR-223.
You should be able to happily continue using a 3.x version of the module with 
Groovy 4.


> Groovy 4.0.0 BSF module does not have a release version in central Maven 
> repository
> ---
>
> Key: GROOVY-10469
> URL: https://issues.apache.org/jira/browse/GROOVY-10469
> Project: Groovy
>  Issue Type: Bug
>  Components: groovy-bsf
>Affects Versions: 4.0.0
>Reporter: Alexander Veit
>Priority: Major
>
> The 4.0.0 version is missing.
> See https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-bsf/



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Created] (GROOVY-10469) Groovy 4.0.0 BSF module does not have a release version in central Maven repository

2022-02-01 Thread Alexander Veit (Jira)
Alexander Veit created GROOVY-10469:
---

 Summary: Groovy 4.0.0 BSF module does not have a release version 
in central Maven repository
 Key: GROOVY-10469
 URL: https://issues.apache.org/jira/browse/GROOVY-10469
 Project: Groovy
  Issue Type: Bug
  Components: groovy-bsf
Affects Versions: 4.0.0
Reporter: Alexander Veit


The 4.0.0 version is missing.

See https://repo.maven.apache.org/maven2/org/apache/groovy/groovy-bsf/




--
This message was sent by Atlassian Jira
(v8.20.1#820001)