[GitHub] [groovy] sbglasius commented on pull request #1422: Create CODE_OF_CONDUCT.md

2020-11-17 Thread GitBox


sbglasius commented on pull request #1422:
URL: https://github.com/apache/groovy/pull/1422#issuecomment-729502362


   Looks good to me



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




[GitHub] [groovy] remkop commented on pull request #1420: GROOVY-9817: Enhance Closure annotation value (as Closure class) to A…

2020-11-17 Thread GitBox


remkop commented on pull request #1420:
URL: https://github.com/apache/groovy/pull/1420#issuecomment-729332322


   Looks good to me. 



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




[jira] [Updated] (GROOVY-9821) STC doesn't recognize interface-based properties

2020-11-17 Thread Christopher Smith (Jira)


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

Christopher Smith updated GROOVY-9821:
--
Description: 
I have been unable to create a more minimal MCVE, but this is reproducible at 
will using the Spring Security libraries.

The following method definition:

{code:groovy}
def authorities(Authentication auth) {
    auth.authorities*.authority
}
{code}

produces an error

{code}
No such property: authority for class: java.util.Collection 
{code}

It should be attempting to spread the property access onto the collection's 
element type, not the collection itself. Using {{*.getAuthority()}} works as 
expected. I could not replicate with an inline Groovy test case; the resolution 
works, but invoking against the {{Authentication}} class reliably produces the 
error. The error occurs in both {{@CompileStatic}} and {{@TypeChecked}}.

Removing static type checking makes Eclipse correctly display the 
interface-based property.

  was:
I have been unable to create a more minimal MCVE, but this is reproducable at 
will using the Spring Security libraries.

The following method definition:

{code:groovy}
def authorities(Authentication auth) {
    auth.authorities*.authority
}
{code}

produces an error

{code}
No such property: authority for class: java.util.Collection 
{code}

It should be attempting to spread the property access onto the collection's 
element type, not the collection itself. Using {{*.getAuthority()}} works as 
expected. I could not replicate with an inline Groovy test case; the resolution 
works, but invoking against the {{Authentication}} class reliably produces the 
error.


> STC doesn't recognize interface-based properties
> 
>
> Key: GROOVY-9821
> URL: https://issues.apache.org/jira/browse/GROOVY-9821
> Project: Groovy
>  Issue Type: Bug
>  Components: Static Type Checker
>Affects Versions: 3.0.6
>Reporter: Christopher Smith
>Priority: Minor
>
> I have been unable to create a more minimal MCVE, but this is reproducible at 
> will using the Spring Security libraries.
> The following method definition:
> {code:groovy}
> def authorities(Authentication auth) {
>     auth.authorities*.authority
> }
> {code}
> produces an error
> {code}
> No such property: authority for class: java.util.Collection  org.springframework.security.core.GrantedAuthority>
> {code}
> It should be attempting to spread the property access onto the collection's 
> element type, not the collection itself. Using {{*.getAuthority()}} works as 
> expected. I could not replicate with an inline Groovy test case; the 
> resolution works, but invoking against the {{Authentication}} class reliably 
> produces the error. The error occurs in both {{@CompileStatic}} and 
> {{@TypeChecked}}.
> Removing static type checking makes Eclipse correctly display the 
> interface-based property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GROOVY-9821) STC doesn't recognize interface-based properties

2020-11-17 Thread Christopher Smith (Jira)
Christopher Smith created GROOVY-9821:
-

 Summary: STC doesn't recognize interface-based properties
 Key: GROOVY-9821
 URL: https://issues.apache.org/jira/browse/GROOVY-9821
 Project: Groovy
  Issue Type: Bug
  Components: Static Type Checker
Affects Versions: 3.0.6
Reporter: Christopher Smith


I have been unable to create a more minimal MCVE, but this is reproducable at 
will using the Spring Security libraries.

The following method definition:

{code:groovy}
def authorities(Authentication auth) {
    auth.authorities*.authority
}
{code}

produces an error

{code}
No such property: authority for class: java.util.Collection 
{code}

It should be attempting to spread the property access onto the collection's 
element type, not the collection itself. Using {{*.getAuthority()}} works as 
expected. I could not replicate with an inline Groovy test case; the resolution 
works, but invoking against the {{Authentication}} class reliably produces the 
error.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [groovy] paulk-asert opened a new pull request #1422: Create CODE_OF_CONDUCT.md

2020-11-17 Thread GitBox


paulk-asert opened a new pull request #1422:
URL: https://github.com/apache/groovy/pull/1422


   



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




[GitHub] [groovy] chrylis commented on pull request #1414: GROOVY-9803: translate generics of method reference using SAM parameters

2020-11-17 Thread GitBox


chrylis commented on pull request #1414:
URL: https://github.com/apache/groovy/pull/1414#issuecomment-729259561


   I'm not sure from reading the code change, but does this handle arbitrarily 
nested generics? The actual real-world type that the compiler is having trouble 
with is (combining Vavr, Spring MVC, and some of my own record types)
   
   ```
Either, 
HeadersAndBody>>
   ```
   
   where invoking `Either#map` expects a `Function>` (this part works) but the 
closure (or Parrot lambda) seems not to correctly preserve the nested type 
parameters into the closure.



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




[jira] [Closed] (GROOVY-9820) Bump gradle to 6.7.1

2020-11-17 Thread Daniel Sun (Jira)


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

Daniel Sun closed GROOVY-9820.
--
Fix Version/s: 4.0.0-alpha-2
   3.0.7
 Assignee: Daniel Sun
   Resolution: Fixed

> Bump gradle to 6.7.1
> 
>
> Key: GROOVY-9820
> URL: https://issues.apache.org/jira/browse/GROOVY-9820
> Project: Groovy
>  Issue Type: Dependency upgrade
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GROOVY-9820) Bump gradle to 6.7.1

2020-11-17 Thread Daniel Sun (Jira)
Daniel Sun created GROOVY-9820:
--

 Summary: Bump gradle to 6.7.1
 Key: GROOVY-9820
 URL: https://issues.apache.org/jira/browse/GROOVY-9820
 Project: Groovy
  Issue Type: Dependency upgrade
Reporter: Daniel Sun






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [groovy] paulk-asert opened a new pull request #1421: GROOVY-9819: bump jsp-api/servlet-api versions to 2.3.3/4.0.1

2020-11-17 Thread GitBox


paulk-asert opened a new pull request #1421:
URL: https://github.com/apache/groovy/pull/1421


   



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




[jira] [Updated] (GROOVY-9819) bump jsp-api/servlet-api versions to 2.3.3/4.0.1

2020-11-17 Thread Paul King (Jira)


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

Paul King updated GROOVY-9819:
--
Summary: bump jsp-api/servlet-api versions to 2.3.3/4.0.1  (was: bump 
jsp-api version to 2.3.3)

> bump jsp-api/servlet-api versions to 2.3.3/4.0.1
> 
>
> Key: GROOVY-9819
> URL: https://issues.apache.org/jira/browse/GROOVY-9819
> Project: Groovy
>  Issue Type: Dependency upgrade
>Reporter: Paul King
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GROOVY-9819) bump jsp-api version to 2.3.3

2020-11-17 Thread Paul King (Jira)
Paul King created GROOVY-9819:
-

 Summary: bump jsp-api version to 2.3.3
 Key: GROOVY-9819
 URL: https://issues.apache.org/jira/browse/GROOVY-9819
 Project: Groovy
  Issue Type: Dependency upgrade
Reporter: Paul King






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GROOVY-9818) JSP-API license seems to be missing

2020-11-17 Thread Alexander Veit (Jira)
Alexander Veit created GROOVY-9818:
--

 Summary: JSP-API license seems to be missing
 Key: GROOVY-9818
 URL: https://issues.apache.org/jira/browse/GROOVY-9818
 Project: Groovy
  Issue Type: Bug
  Components: release
Affects Versions: 3.0.6
Reporter: Alexander Veit


The license for the JSP-API (jsp-api-2.0.jar, CDDL) seems to be missing in the 
Groovy binary distribution (licenses directory and JAR itself).




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GROOVY-9817) Enhance Closure annotation value (as Closure class) to Arrays

2020-11-17 Thread Remko Popma (Jira)


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

Remko Popma updated GROOVY-9817:

Description: 
The background for this request is annotations in the 
[picocli|https://picocli.info/] library. The annotations API of this library 
allows applications to specify a class or an array of classes to customize some 
behaviour. For example:
{code:java}
// current picocli (4.5.2) requires explicit class(es), does not support 
Closures
@Option(names = "-x",
completionCandidates = MyCandidates.class, 
converter = [StringConverter.class, MessageDigestConverter.class])
Map someOption;
{code}
There is [work in progress|https://github.com/remkop/picocli/issues/1258] in 
the picocli library to allow applications to specify closures for such classes 
in the annotations. For example, I would like applications to be able to do 
this:
{code:java}
// next version of picocli (4.6.0) aims to support Closures in these annotation 
attributes
@picocli.CommandLine.Option(names = "-x",
completionCandidates = {["A", "B", "C"]},
converter = [ {it}, { str -> 
java.security.MessageDigest.getInstance(str) } ])
Map someOption
{code}
With the current version of Groovy (3.0.6), this works for the single-value 
attributes like {{completionCandidates}}, but does not work for attributes that 
take an array of values, like {{converter}}.

Please add support for arrays in the Closure to Class conversion for 
annotations.

See also 
[discussion|https://lists.apache.org/thread.html/rcd541adf064adb6839b79c889a5778a80739837a58adce523f86e660%40]
 on the groovy-dev mailing list.

  was:
The background for this request is annotations in the 
[picocli|https://picocli.info/] library. The annotations API of this library 
allows applications to specify a class or an array of classes to customize some 
behaviour. For example:
{code:java}
// current picocli (4.5.2) requires explicit class(es), does not support 
Closures
@Option(names = "-x",
completionCandidates = MyCandidates.class, 
converter = [StringConverter.class, MessageDigestConverter.class])
Map someOption;
{code}
There is [work in progress|https://github.com/remkop/picocli/issues/1258] in 
the picocli library to allow applications to specify closures for such classes 
in the annotations. For example, I would like applications to be able to do 
this:
{code:java}
// next version of picocli (4.6.0) aims to support Closures in these annotation 
attributes
@picocli.CommandLine.Option(names = "-x",
completionCandidates = {["A", "B", "C"]},
converter = [ {it}, { str -> 
java.security.MessageDigest.getInstance(str) } ])
Map someOption
{code}
With the current version of Groovy (3.0.6), this works for the single-value 
attributes like {{completionCandidates}}, but does not work for attributes that 
take an array of values, like {{converter}}.

Please add support for arrays in the Closure to Class conversion for 
annotations.


> Enhance Closure annotation value (as Closure class) to Arrays
> -
>
> Key: GROOVY-9817
> URL: https://issues.apache.org/jira/browse/GROOVY-9817
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The background for this request is annotations in the 
> [picocli|https://picocli.info/] library. The annotations API of this library 
> allows applications to specify a class or an array of classes to customize 
> some behaviour. For example:
> {code:java}
> // current picocli (4.5.2) requires explicit class(es), does not support 
> Closures
> @Option(names = "-x",
> completionCandidates = MyCandidates.class, 
> converter = [StringConverter.class, MessageDigestConverter.class])
> Map someOption;
> {code}
> There is [work in progress|https://github.com/remkop/picocli/issues/1258] in 
> the picocli library to allow applications to specify closures for such 
> classes in the annotations. For example, I would like applications to be able 
> to do this:
> {code:java}
> // next version of picocli (4.6.0) aims to support Closures in these 
> annotation attributes
> @picocli.CommandLine.Option(names = "-x",
> completionCandidates = {["A", "B", "C"]},
> converter = [ {it}, { str -> 
> java.security.MessageDigest.getInstance(str) } ])
> Map someOption
> {code}
> With the current version of Groovy (3.0.6), this works for the single-value 
> attributes like {{completionCandidates}}, but does not work for attributes 
> that take an array of values, like {{converter}}.
> Please add support for arrays in the Closure to Class conversion for 
> annotations.
> See also 
> 

[jira] [Updated] (GROOVY-9817) Enhance Closure annotation value (as Closure class) to Arrays

2020-11-17 Thread Remko Popma (Jira)


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

Remko Popma updated GROOVY-9817:

Issue Type: New Feature  (was: Dependency upgrade)

> Enhance Closure annotation value (as Closure class) to Arrays
> -
>
> Key: GROOVY-9817
> URL: https://issues.apache.org/jira/browse/GROOVY-9817
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The background for this request is annotations in the 
> [picocli|https://picocli.info/] library. The annotations API of this library 
> allows applications to specify a class or an array of classes to customize 
> some behaviour. For example:
> {code:java}
> // current picocli (4.5.2) requires explicit class(es), does not support 
> Closures
> @Option(names = "-x",
> completionCandidates = MyCandidates.class, 
> converter = [StringConverter.class, MessageDigestConverter.class])
> Map someOption;
> {code}
> There is [work in progress|https://github.com/remkop/picocli/issues/1258] in 
> the picocli library to allow applications to specify closures for such 
> classes in the annotations. For example, I would like applications to be able 
> to do this:
> {code:java}
> // next version of picocli (4.6.0) aims to support Closures in these 
> annotation attributes
> @picocli.CommandLine.Option(names = "-x",
> completionCandidates = {["A", "B", "C"]},
> converter = [ {it}, { str -> 
> java.security.MessageDigest.getInstance(str) } ])
> Map someOption
> {code}
> With the current version of Groovy (3.0.6), this works for the single-value 
> attributes like {{completionCandidates}}, but does not work for attributes 
> that take an array of values, like {{converter}}.
> Please add support for arrays in the Closure to Class conversion for 
> annotations.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GROOVY-9817) Enhance Closure annotation value (as Closure class) to Arrays

2020-11-17 Thread Remko Popma (Jira)


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

Remko Popma updated GROOVY-9817:

Description: 
The background for this request is annotations in the 
[picocli|https://picocli.info/] library. The annotations API of this library 
allows applications to specify a class or an array of classes to customize some 
behaviour. For example:
{code:java}
// current picocli (4.5.2) requires explicit class(es), does not support 
Closures
@Option(names = "-x",
completionCandidates = MyCandidates.class, 
converter = [StringConverter.class, MessageDigestConverter.class])
Map someOption;
{code}
There is [work in progress|https://github.com/remkop/picocli/issues/1258] in 
the picocli library to allow applications to specify closures for such classes 
in the annotations. For example, I would like applications to be able to do 
this:
{code:java}
// next version of picocli (4.6.0) aims to support Closures in these annotation 
attributes
@picocli.CommandLine.Option(names = "-x",
completionCandidates = {["A", "B", "C"]},
converter = [ {it}, { str -> 
java.security.MessageDigest.getInstance(str) } ])
Map someOption
{code}
With the current version of Groovy (3.0.6), this works for the single-value 
attributes like {{completionCandidates}}, but does not work for attributes that 
take an array of values, like {{converter}}.

Please add support for arrays in the Closure to Class conversion for 
annotations.

> Enhance Closure annotation value (as Closure class) to Arrays
> -
>
> Key: GROOVY-9817
> URL: https://issues.apache.org/jira/browse/GROOVY-9817
> Project: Groovy
>  Issue Type: Dependency upgrade
>Reporter: Paul King
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The background for this request is annotations in the 
> [picocli|https://picocli.info/] library. The annotations API of this library 
> allows applications to specify a class or an array of classes to customize 
> some behaviour. For example:
> {code:java}
> // current picocli (4.5.2) requires explicit class(es), does not support 
> Closures
> @Option(names = "-x",
> completionCandidates = MyCandidates.class, 
> converter = [StringConverter.class, MessageDigestConverter.class])
> Map someOption;
> {code}
> There is [work in progress|https://github.com/remkop/picocli/issues/1258] in 
> the picocli library to allow applications to specify closures for such 
> classes in the annotations. For example, I would like applications to be able 
> to do this:
> {code:java}
> // next version of picocli (4.6.0) aims to support Closures in these 
> annotation attributes
> @picocli.CommandLine.Option(names = "-x",
> completionCandidates = {["A", "B", "C"]},
> converter = [ {it}, { str -> 
> java.security.MessageDigest.getInstance(str) } ])
> Map someOption
> {code}
> With the current version of Groovy (3.0.6), this works for the single-value 
> attributes like {{completionCandidates}}, but does not work for attributes 
> that take an array of values, like {{converter}}.
> Please add support for arrays in the Closure to Class conversion for 
> annotations.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)