[jira] [Created] (GROOVY-10575) groovysh can't launch in m1 mac

2022-04-07 Thread jackyHu (Jira)
jackyHu created GROOVY-10575:


 Summary: groovysh can't launch in m1 mac
 Key: GROOVY-10575
 URL: https://issues.apache.org/jira/browse/GROOVY-10575
 Project: Groovy
  Issue Type: Bug
  Components: Groovysh
Affects Versions: 4.0.1
Reporter: jackyHu


when I run groovysh, I got this 

```

java.lang.reflect.InvocationTargetException

 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)

 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)

 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

 at java.base/java.lang.reflect.Method.invoke(Method.java:568)

 at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:112)

 at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)

Caused by: java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no 
jansi in java.library.path: 
/Users/jackyhu/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.,
 
/private/var/folders/2l/2h6n93td2_x8_0n41206cvyrgn/T/libjansi-64-2557396990353272192.jnilib:
 
dlopen(/private/var/folders/2l/2h6n93td2_x8_0n41206cvyrgn/T/libjansi-64-2557396990353272192.jnilib,
 0x0001): tried: 
'/private/var/folders/2l/2h6n93td2_x8_0n41206cvyrgn/T/libjansi-64-2557396990353272192.jnilib'
 (fat file, but missing compatible architecture (have 'x86_64,i386', need 
'arm64e'))]

 at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)

 at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)

 at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)

 at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)

 at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)

 at java.base/java.lang.Class.forName0(Native Method)

 at java.base/java.lang.Class.forName(Class.java:467)

 at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.lambda$createCallStaticSite$2(CallSiteArray.java:64)

 at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)

 at org.codehaus.groovy.vmplugin.v8.Java8.doPrivileged(Java8.java:628)

 at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallStaticSite(CallSiteArray.java:62)

 at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:155)

 at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:46)

 at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)

 at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)

 at org.apache.groovy.groovysh.Main.installAnsi(Main.groovy:249)

 at org.apache.groovy.groovysh.Main.setTerminalType(Main.groovy:235)

 at org.apache.groovy.groovysh.Main.main(Main.groovy:120)

```



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


[jira] [Commented] (GROOVY-10571) Stub generator misses sibling classes in annotation

2022-04-07 Thread Christopher Smith (Jira)


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

Christopher Smith commented on GROOVY-10571:


Thanks, I'll try {{Type.class}} and let you know!




-- 
Christopher Smith


> Stub generator misses sibling classes in annotation
> ---
>
> Key: GROOVY-10571
> URL: https://issues.apache.org/jira/browse/GROOVY-10571
> Project: Groovy
>  Issue Type: Bug
>  Components: Stub generator / Joint compiler
>Affects Versions: 4.0.1
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> To work around [a DynamoDB SDK bug that just turned 
> one|https://github.com/aws/aws-sdk-java-v2/issues/2347], I created an 
> attribute converter that ignores {{MetaClass}} and an {{AnnotationCollector}} 
> that applies it to record classes with some other usual POJO bits.
> The annotation collector is in the same package as the converter-prvider Java 
> class. Running the stub generator produces this output (line breaks added):
> {code}
> @groovy.transform.AnnotationCollector()
> @software.amazon.awssdk.enhanced.dynamodb.mapper.annotations.DynamoDbBean(converterProviders={IgnoreMetaClassAttributeConverterProvider,software.amazon.awssdk.enhanced.dynamodb.DefaultAttributeConverterProvider.class})
> @groovy.transform.stc.POJO()
> @java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.SOURCE)
>  @java.lang.annotation.Target(value=java.lang.annotation.ElementType.TYPE) 
> public @interface DynamoDbRecord2{;}
> {code}
> Note the missing {{.class}} on the first class argument (which is not 
> imported and is present in the same package, but is a Java file).



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


[jira] [Commented] (GROOVY-10571) Stub generator misses sibling classes in annotation

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles commented on GROOVY-10571:
--

You should be able to use an explicit class expression "Type.class" as a 
workaround.  Or you could extend the referenced java type with a groovy type 
and use that as your type reference.

> Stub generator misses sibling classes in annotation
> ---
>
> Key: GROOVY-10571
> URL: https://issues.apache.org/jira/browse/GROOVY-10571
> Project: Groovy
>  Issue Type: Bug
>  Components: Stub generator / Joint compiler
>Affects Versions: 4.0.1
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> To work around [a DynamoDB SDK bug that just turned 
> one|https://github.com/aws/aws-sdk-java-v2/issues/2347], I created an 
> attribute converter that ignores {{MetaClass}} and an {{AnnotationCollector}} 
> that applies it to record classes with some other usual POJO bits.
> The annotation collector is in the same package as the converter-prvider Java 
> class. Running the stub generator produces this output (line breaks added):
> {code}
> @groovy.transform.AnnotationCollector()
> @software.amazon.awssdk.enhanced.dynamodb.mapper.annotations.DynamoDbBean(converterProviders={IgnoreMetaClassAttributeConverterProvider,software.amazon.awssdk.enhanced.dynamodb.DefaultAttributeConverterProvider.class})
> @groovy.transform.stc.POJO()
> @java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.SOURCE)
>  @java.lang.annotation.Target(value=java.lang.annotation.ElementType.TYPE) 
> public @interface DynamoDbRecord2{;}
> {code}
> Note the missing {{.class}} on the first class argument (which is not 
> imported and is present in the same package, but is a Java file).



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


[jira] [Commented] (GROOVY-10571) Stub generator misses sibling classes in annotation

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles commented on GROOVY-10571:
--

Test case that recreates the described condition: 
https://github.com/apache/groovy/commit/4545a8bafe0804d66a7c3380f6cc752234e5ceca

> Stub generator misses sibling classes in annotation
> ---
>
> Key: GROOVY-10571
> URL: https://issues.apache.org/jira/browse/GROOVY-10571
> Project: Groovy
>  Issue Type: Bug
>  Components: Stub generator / Joint compiler
>Affects Versions: 4.0.1
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> To work around [a DynamoDB SDK bug that just turned 
> one|https://github.com/aws/aws-sdk-java-v2/issues/2347], I created an 
> attribute converter that ignores {{MetaClass}} and an {{AnnotationCollector}} 
> that applies it to record classes with some other usual POJO bits.
> The annotation collector is in the same package as the converter-prvider Java 
> class. Running the stub generator produces this output (line breaks added):
> {code}
> @groovy.transform.AnnotationCollector()
> @software.amazon.awssdk.enhanced.dynamodb.mapper.annotations.DynamoDbBean(converterProviders={IgnoreMetaClassAttributeConverterProvider,software.amazon.awssdk.enhanced.dynamodb.DefaultAttributeConverterProvider.class})
> @groovy.transform.stc.POJO()
> @java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.SOURCE)
>  @java.lang.annotation.Target(value=java.lang.annotation.ElementType.TYPE) 
> public @interface DynamoDbRecord2{;}
> {code}
> Note the missing {{.class}} on the first class argument (which is not 
> imported and is present in the same package, but is a Java file).



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


[jira] [Commented] (GROOVY-10571) Stub generator misses sibling classes in annotation

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles commented on GROOVY-10571:
--

A name is resolved as a class reference here: 
https://github.com/apache/groovy/blob/master/src/main/java/org/codehaus/groovy/control/ResolveVisitor.java#L1014

In the case of groovy references java, there is no link in the compilation unit 
/ module node back to the java class.  And without making a replacement from 
VariableExpression to ClassExpression, the name is written without a ".class" 
suffix.

> Stub generator misses sibling classes in annotation
> ---
>
> Key: GROOVY-10571
> URL: https://issues.apache.org/jira/browse/GROOVY-10571
> Project: Groovy
>  Issue Type: Bug
>  Components: Stub generator / Joint compiler
>Affects Versions: 4.0.1
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> To work around [a DynamoDB SDK bug that just turned 
> one|https://github.com/aws/aws-sdk-java-v2/issues/2347], I created an 
> attribute converter that ignores {{MetaClass}} and an {{AnnotationCollector}} 
> that applies it to record classes with some other usual POJO bits.
> The annotation collector is in the same package as the converter-prvider Java 
> class. Running the stub generator produces this output (line breaks added):
> {code}
> @groovy.transform.AnnotationCollector()
> @software.amazon.awssdk.enhanced.dynamodb.mapper.annotations.DynamoDbBean(converterProviders={IgnoreMetaClassAttributeConverterProvider,software.amazon.awssdk.enhanced.dynamodb.DefaultAttributeConverterProvider.class})
> @groovy.transform.stc.POJO()
> @java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.SOURCE)
>  @java.lang.annotation.Target(value=java.lang.annotation.ElementType.TYPE) 
> public @interface DynamoDbRecord2{;}
> {code}
> Note the missing {{.class}} on the first class argument (which is not 
> imported and is present in the same package, but is a Java file).



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


[jira] [Assigned] (GROOVY-10571) Stub generator misses sibling classes in annotation

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles reassigned GROOVY-10571:


Assignee: Eric Milles

> Stub generator misses sibling classes in annotation
> ---
>
> Key: GROOVY-10571
> URL: https://issues.apache.org/jira/browse/GROOVY-10571
> Project: Groovy
>  Issue Type: Bug
>  Components: Stub generator / Joint compiler
>Affects Versions: 4.0.1
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> To work around [a DynamoDB SDK bug that just turned 
> one|https://github.com/aws/aws-sdk-java-v2/issues/2347], I created an 
> attribute converter that ignores {{MetaClass}} and an {{AnnotationCollector}} 
> that applies it to record classes with some other usual POJO bits.
> The annotation collector is in the same package as the converter-prvider Java 
> class. Running the stub generator produces this output (line breaks added):
> {code}
> @groovy.transform.AnnotationCollector()
> @software.amazon.awssdk.enhanced.dynamodb.mapper.annotations.DynamoDbBean(converterProviders={IgnoreMetaClassAttributeConverterProvider,software.amazon.awssdk.enhanced.dynamodb.DefaultAttributeConverterProvider.class})
> @groovy.transform.stc.POJO()
> @java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.SOURCE)
>  @java.lang.annotation.Target(value=java.lang.annotation.ElementType.TYPE) 
> public @interface DynamoDbRecord2{;}
> {code}
> Note the missing {{.class}} on the first class argument (which is not 
> imported and is present in the same package, but is a Java file).



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


[jira] [Updated] (GROOVY-10367) STC fails to infer the correct type for type variable in the presence of the diamond operator and bounded polymorphism

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10367:
-
Fix Version/s: 3.0.11

> STC fails to infer the correct type for type variable in the presence of the 
> diamond operator and bounded polymorphism
> --
>
> Key: GROOVY-10367
> URL: https://issues.apache.org/jira/browse/GROOVY-10367
> Project: Groovy
>  Issue Type: Bug
>  Components: Static Type Checker
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Major
> Fix For: 5.0.0-alpha-1, 3.0.11, 4.0.2
>
>
> This issue may be related to GROOVY-10343.
> I have the following program
> {code:java}
> class A {
>   Z f;
>   A(Z f) {}
> }
> class B {
>   Z f;
>   void test() {
> f = new A<>((Z) null).f;
>   }
> }
> {code}
> h3. Actual behaviour
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
> failed:
> test.groovy: 10: [Static type checking] - Cannot assign value of type 
> java.lang.Object to variable of type Z
>  @ line 10, column 9.
>f = new A<>((Z) null).f;
>^
> 1 error
> {code}
> h3. Expected behaviour
> Compile successfully
> NOTE: Replacing `Z extends Number` with `Z` leads to a successful compilation.
> Tested against master 
> (https://github.com/apache/groovy/commit/cf2f77fb033a10d36c4db3a7ff07a2b04631afcf)



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


[jira] [Updated] (GROOVY-10324) STC is unable to infer type variable when combining parameterized types and the diamond operator

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10324:
-
Fix Version/s: 3.0.11

> STC is unable to infer type variable when combining parameterized types and 
> the diamond operator
> 
>
> Key: GROOVY-10324
> URL: https://issues.apache.org/jira/browse/GROOVY-10324
> Project: Groovy
>  Issue Type: Bug
>Reporter: Thodoris Sotiropoulos
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-2, 3.0.11
>
>
> I have the following program
> {code:java}
> class A {
>T foo(C t) { return null; }
> }
> class C {}
> class B {
>   void test() {
> C x = (new A()).foo(new C<>());
>   }
> }
> {code}
> h3. Actual behaviour
> {code}
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
> failed:
> test.groovy: 12: [Static type checking] - Cannot assign value of type 
> java.lang.Object to variable of type C
>  @ line 12, column 19.
>C x = (new A()).foo(new C<>());
>  ^
> 1 error
> {code}
> h3. Expected behaviour
> Compile successfully
> Note that compilation fails only if the expected return type is parameterized 
> (i.e., `D`). If I replace the declared type of `x` with a regular 
> type (i.e., `String`), the code compiles fine.
> Tested against master.



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


[jira] [Updated] (GROOVY-10235) STC: Generic type of Set not correctly resolved when calling ConcurrentHashMap.newKeySet()

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10235:
-
Fix Version/s: 3.0.11

> STC: Generic type of Set not correctly resolved when calling 
> ConcurrentHashMap.newKeySet()
> --
>
> Key: GROOVY-10235
> URL: https://issues.apache.org/jira/browse/GROOVY-10235
> Project: Groovy
>  Issue Type: Bug
>  Components: Static Type Checker
>Affects Versions: 4.0.0-beta-1
> Environment: OpenJDK 8
>Reporter: Lyuben Atanasov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-2, 3.0.11
>
>
> The following code fails to compile when STC is enabled:
> {code}
> import java.util.concurrent.ConcurrentHashMap;
> class Test {
> public void test() {
> Set integers = ConcurrentHashMap.newKeySet();
> integers.add(1);
> integers.add(2);
> printSet(integers);
> }
> private void printSet(Set integers) {
> println "$integers";
> }
> }
> {code}
> The error reported by the compiler is:
> {noformat}
> Exception in thread "main" 
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
> failed:
> Script_a26d7b8defa71ea9b230673f8bc53d80.groovy: 9: [Static type checking] - 
> Cannot call Test#printSet(java.util.Set) with arguments 
> [java.util.concurrent.ConcurrentHashMap$KeySetView java.lang.Object>]
>  @ line 9, column 9.
>printSet(integers);
>^
> {noformat}
> This issue is new to 4.0.0-beta-1, it has not been observed before that. It 
> looks like the variable definition is treated as if it was {{def integers}} 
> so the generic type of the Set is not correctly resolved.



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


[jira] [Updated] (GROOVY-9033) Bad code green: empty list literal with each method

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-9033:

Fix Version/s: 3.0.11

> Bad code green: empty list literal with each method
> ---
>
> Key: GROOVY-9033
> URL: https://issues.apache.org/jira/browse/GROOVY-9033
> Project: Groovy
>  Issue Type: Bug
>  Components: Static Type Checker
>Affects Versions: 2.5.6
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-1, 3.0.11
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {code:groovy}
> @groovy.transform.CompileStatic
> List usage() {
>   def l = [].each {}
>   return l // expected error: Incompatible generic argument types. Cannot 
> assign java.util.List  to: java.util.List  
> }{code}



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


[jira] [Updated] (GROOVY-10089) SC: GroovyCastException for map value as constructor for Collection

2022-04-07 Thread Eric Milles (Jira)


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

Eric Milles updated GROOVY-10089:
-
Fix Version/s: 3.0.11

> SC: GroovyCastException for map value as constructor for Collection
> ---
>
> Key: GROOVY-10089
> URL: https://issues.apache.org/jira/browse/GROOVY-10089
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-beta-1, 3.0.11
>
>
> Our tree-building code is a bit more than this, but I was able to trim back 
> and still produce the run-time exception:
> {code:groovy}
> def test(... attributes) {
> List one = [
> [id:'x', options:[count:1]]
> ]
> List two = attributes.collect {
> def node = Collections.singletonMap('children', one)
> if (node) {
> node = node.get('children').find { child -> child['id'] == 'x' }
> }
> // inferred type of node must be something like Map>
> [id: it['id'], name: node['name'], count: node['options']['count']]
> //^^^ 
> GroovyCastException (map ctor for Collection)
> }
> two
> }
> test( [id:'x'] )
> {code}
> Changing the type of "one" from "List" to "def" stops the madness.



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


[jira] [Created] (GROOVY-10574) @NamedVariant generation does not work with extension methods

2022-04-07 Thread Jira
Leonard Brünings created GROOVY-10574:
-

 Summary: @NamedVariant generation does not work with extension 
methods
 Key: GROOVY-10574
 URL: https://issues.apache.org/jira/browse/GROOVY-10574
 Project: Groovy
  Issue Type: Bug
Affects Versions: 4.0.1, 3.0.10, 2.5.16
Reporter: Leonard Brünings


Based on the discussion in GROOVY-10567 I tried creating a extension method by 
explicitly annotating the other parameters with {{@NamedParam}}. However, the 
method was not picked up as an extension method.

As an example:

{code:groovy}
import groovy.transform.*

@NamedVariant
static javaBlockingTest(File self,
 @NamedParam String packageName = 'com.example',
 @NamedParam String className = "BlockingTest") {
}
{code}

will generate as 

{code:groovy}
@groovy.transform.Generated
public static java.lang.Object 
javaBlockingTest(@groovy.transform.NamedParams(value = 
[@groovy.transform.NamedParam(value = 'packageName', type = java.lang.String), 
@groovy.transform.NamedParam(value = 'className', type = java.lang.String)]) 
java.util.Map namedArgs, java.io.File self) {
if ( namedArgs == null) {
throw new java.lang.IllegalArgumentException('Named parameter map 
cannot be null')
}
for (java.lang.String namedArgKey : namedArgs.keySet()) {
assert ['self', 'packageName', 'className'].contains( namedArgKey ) 
: 'Unrecognized namedArgKey: ' + namedArgKey }
return this.javaBlockingTest(self, namedArgs.containsKey('packageName') 
? namedArgs.packageName : 'com.example', namedArgs.containsKey('className') ? 
namedArgs.className : 'BlockingTest')
}
{code}

Important to note is that the {{namedArgs}} parameter was moved before the 
{{self}} parameter, basically shifting the extended type from {{File}} to 
{{Map}}.

If we handcraft

{code:groovy}
public static java.lang.Object javaBlockingTest(java.io.File self, 
@groovy.transform.NamedParams(value = [@groovy.transform.NamedParam(value = 
'packageName', type = java.lang.String), @groovy.transform.NamedParam(value = 
'className', type = java.lang.String)]) java.util.Map namedArgs) {
}
{code}

it works as expected.

IMHO we would need a flag {{@NamedVariant(extensionMethod = true)}}, which 
changes the generated code by preserving the first parameter. 




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


[GitHub] [groovy] paulk-asert commented on pull request #1710: groovy-bom dependency has no LICENSE

2022-04-07 Thread GitBox


paulk-asert commented on PR #1710:
URL: https://github.com/apache/groovy/pull/1710#issuecomment-1091651939

   It looks like it would be safe (and in fact desirable) for you to set the 
`:checkLicense` `excludeBoms` property to true.
   The relevant code is here:
   
https://github.com/jk1/Gradle-License-Report/blob/master/src/main/groovy/com/github/jk1/license/LicenseReportExtension.groovy#L97
   So, if I understand correctly, it will not try to check boms if there is no 
jar artifact.


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