[jira] [Created] (GROOVY-9002) groovy-all-2.5.4-indy.jar not available in mavenCentral or jcenter
will mason created GROOVY-9002:
--
Summary: groovy-all-2.5.4-indy.jar not available in mavenCentral
or jcenter
Key: GROOVY-9002
URL: https://issues.apache.org/jira/browse/GROOVY-9002
Project: Groovy
Issue Type: Bug
Components: groovy-runtime
Affects Versions: 2.5.4
Environment: Groovy / Gradle 5
Reporter: will mason
Our Gradle build automatically looks for the Groovy version that matches the
installed Gradel version. This is done because sometimes having an
incompatible Groovy version with the build causes exceptions in the build.
Therefore it is impretive for the matching Groovy artefact be available in the
central repositories.
{noformat}
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all files for configuration
':TestingSupport:compileClasspath'.
> Could not find groovy-all-indy.jar (org.codehaus.groovy:groovy-all:2.5.4).
{noformat}
I've looked in both {{mavenCentral}} and {{jcenter}} and the {{groovy-all}}
indy file is not present.
The [Invoke dynamic support|http://groovy-lang.org/indy.html] documentation
page reports that there are two versions of the Groovy all .JAR used.
The absence of this JAR breaks our build.
If Groovy is no longer supporting the {{-indy}} version of the JAR-s this
should be noted in the documentation. I could find nothing about Invoke
Dynamic in the [Groovy 2.5 release
notes|http://groovy-lang.org/releasenotes/groovy-2.5.html#releasenotes].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8918) Illegal Reflective Access reported during Gradle build
will mason created GROOVY-8918:
--
Summary: Illegal Reflective Access reported during Gradle build
Key: GROOVY-8918
URL: https://issues.apache.org/jira/browse/GROOVY-8918
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 2.4.15
Environment: Linux 64-bit , gradle 4.10.3, JDK 8 u192 with Netbeans 8.2
Reporter: will mason
The following code is emitted for a Java/Groovy build using Gradle v4.10.3 and
using the Spock BDD testing framework, JDK 8 targeting JRE 8. The message says
to report this.
I didn't find an open bug with this message -- Towit, I'm reporting it.
{code:java}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.codehaus.groovy.reflection.CachedClass
(file:/scr/root/.caches/william/gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-all/2.4.15/5f71e0843ea6c949920f3219c6c961a3895e53c4/groovy-all-2.4.15-indy.jar)
to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of
org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Note: Creating bean classes for 2 type elements
warning: Implicitly compiled files were not subject to annotation processing.
Use -implicit to specify a policy for implicit compilation.
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8846) Embeddable groovy-all-X.XX.jar and groovy-all-X.XX-indy.jar not Included in SDKMAN package(s)
will mason created GROOVY-8846:
--
Summary: Embeddable groovy-all-X.XX.jar and
groovy-all-X.XX-indy.jar not Included in SDKMAN package(s)
Key: GROOVY-8846
URL: https://issues.apache.org/jira/browse/GROOVY-8846
Project: Groovy
Issue Type: Bug
Components: release
Affects Versions: 2.5.3, 2.5.2
Environment: Linux 64 bit
Reporter: will mason
h3. Expected
* Waned to configure {{groovy-all}} JAR for Netbeans and Gradle
* Used SDKMAN as recommended for Ubuntu (Linux) systems
* Neither recent version has the groogy-all embeddable folder
* Not found in any of the {{candidate/groovy/}} folders of the packages.
* As an extra step, I downloaded the available v2.5 ZIP files -- Not present in
these Also.
** Particularly the groovy-all is missing from the SDK bundle.
** I fully expected an SDK to contain all the embeddable modules.
h3. Requirement
* On the IDE page there's a link indicating Groovy is supported by netbeans
* This support requires users to sent the Groovy-all library
* The groovy that comes with Netbeans 8.2 is quite dated now and Netbeans 9 is
not production ready.
* Also Gradle ships with it's required version of embeddable JAR(-s)
** It strikes me that if I wanted to test or use gradle with a plugin or code
that might need a newer version of Gradle that would not be easy to do
h3. Mitigation / Workaround
* I have not yet found a pre-build embeddable/groovy-all-XX JAR
* I can only suggest we build out own
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8339) Fix warning "An illegal reflective access operation has occurred"
[
https://issues.apache.org/jira/browse/GROOVY-8339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16410547#comment-16410547
]
will mason commented on GROOVY-8339:
This error occurs with java *10* (*18.03*) on Groovy 2.4.12 and *2.4.14* which
seems to be the current Release/Production version. JDK 9 is done now.
This problem appears to have effects. Plugins and tests that depend on Groovy
can find they don't like the problem.
```
D:> groovy -version
Groovy Version: 2.4.14 JVM: 1.8.0_162 Vendor: Oracle Corporation OS: Windows 10
D:> SET JAVA_HOME=b:\lang\java\jre\v10.00\x64
D:> groovy -version
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.codehaus.groovy.reflection.CachedClass
(file:/b:/lang/groovy/v02.04/lib/groovy-2.4.14.jar) to method
java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of
org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Groovy Version: 2.4.14 JVM: 10 Vendor: "Oracle Corporation" OS: Windows 10
```
> Fix warning "An illegal reflective access operation has occurred"
> -
>
> Key: GROOVY-8339
> URL: https://issues.apache.org/jira/browse/GROOVY-8339
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Affects Versions: 2.4.11
> Environment: >gradle --version
> Gradle 4.2
> Build time: 2017-09-20 14:48:23 UTC
> Revision: 5ba503cc17748671c83ce35d7da1cffd6e24dfbd
> Groovy: 2.4.11
> Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM: 9 (Oracle Corporation 9+181)
> OS: Windows 10 10.0 amd64
>Reporter: Benjamin Roedell
>Priority: Minor
> Labels: newbie, security
>
> I'm running JDK-9 on Windows 10 with Gradle 4.2.
> My global gradle.properties file contains the following line:
> org.gradle.java.home=C:/Program Files/Java/jdk-9
> When I request the gradle version (gradle --version) I get the following
> warning:
> {code:none}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/C:/Program%20Files/gradle-4.2/lib/groovy-all-2.4.11.jar) to method
> java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> This warning displayed regardless of whether I'm using a regular command
> prompt or an elevated rights (Administrator) command prompt.
> Here's the full command and output:
> {code:none}
> gradle --version
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/C:/Program%20Files/gradle-4.2/lib/groovy-all-2.4.11.jar) to method
> java.lang.Object.finalize()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
>
> Gradle 4.2
>
> Build time: 2017-09-20 14:48:23 UTC
> Revision: 5ba503cc17748671c83ce35d7da1cffd6e24dfbd
> Groovy: 2.4.11
> Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM: 9 (Oracle Corporation 9+181)
> OS: Windows 10 10.0 amd64
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-4189) Removing a metaClass method
[
https://issues.apache.org/jira/browse/GROOVY-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713193#comment-15713193
]
will mason edited comment on GROOVY-4189 at 12/1/16 9:57 PM:
-
G'day, It looks as if this request is still open, which is good.
I have two use-cases.
# Firstly you want to remove a method
# Second you may need to replace / update a certain method
#* Not an override
The second case may not be at issue, however if you can't set the method
dispatch to null, then I suspect that is the same problem.
I have one suggestion. If there is a means provided to '_identify_' the
method, get the signature, then one might have a possible mechanism to only
remove specific method(s) (and/or propert(ies)) .
Something like the following
{code:groovy:title=Bar.java|borderStyle=solid}
candidates = Test.metaClass.getSignatures( "foo" )
// ==> collection of signatures for matches
candidates.each {
if () {
killList.add( it )
}
}
Test.metaClass.remove( killList )
{code}
When you have the list of all possibilities -- The user/programmer can choose.
Other options become difficult because the language can err by deleting too
many or not enough.
This way might mean some explicit administration by the programmer, however it
also demonstrates that what they wish to do is not just a "straightforward
remove" as it were.
was (Author: aplatypus):
G'day, It looks as if this request is still open, which is good.
I have two use-cases.
# Firstly you want to remove a method
# Second you may need to replace / update a certain method
#* Not an override
The second case may not be at issue, however if you can't set the method
dispatch to null, then I suspect that is the same problem.
I have one suggestion. If there is a means provided to '_identify_' the
method, get the signature, then one might have a possible mechanism to only
remove specific method(s) (and/or propert(ies)) .
Something like the following
{code:groovy:title=Bar.java|borderStyle=solid}
candidates = Test.metaClass.getSignatures( "foo" ) ==> collection of
signatures for matches
candidates.each {
if () {
killList.add( it )
}
}
Test.metaClass.remove( killList )
{code}
When you have the list of all possibilities -- The user/programmer can choose.
Other options become difficult because the language can err by deleting too
many or not enough.
This way might mean some explicit administration by the programmer, however it
also demonstrates that what they wish to do is not just a "straightforward
remove" as it were.
> Removing a metaClass method
> ---
>
> Key: GROOVY-4189
> URL: https://issues.apache.org/jira/browse/GROOVY-4189
> Project: Groovy
> Issue Type: Improvement
> Components: groovy-jdk
>Affects Versions: 1.7.2
>Reporter: Tim Yates
>Priority: Minor
> Fix For: 3.0
>
>
> Spotted a question on stackoverflow about removing a metaclass method
> The page here
> http://groovy.codehaus.org/JN3525-MetaClasses
> Says you should be able to do it by setting it to null, but we get this:
> {code}
> String.metaClass.foo = { "${delegate}foo" }
> assert 'kung'.foo() == 'kungfoo'
> String.metaClass.foo = null
> assert 'woo'.foo() == 'woofoo'
> {code}
> That last assert should fail (according to the docs), but it passes
> Is this a documentation issue?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
