Re: [VOTE] Release Apache Groovy 3.0.0-alpha-1

Hi Daniel, we have the same issue in spock, when a file produced by the build is used by gradle later on the daemon keeps it locked. Make sure that no daemon is already running, `gradlew --stop` then `gradlew clean dist --no-daemon` should work Cheers -Leonard P.S. As Paul suggested I'd

Re: Building Groovy

download the distribution. So I see the groovy-all jar as a nice to have but not necessarily essential. Cheers, Paul. On Thu, Nov 23, 2017 at 5:22 AM, Leonard Brünings <groovy-...@bruenings-it.net <mailto:groovy-...@bruenings-it.net>> wrote: I agree with Cédric, that is also w

Re: Building Groovy

I agree with Cédric, that is also what I suggested before. With maven/gradle the usage of groovy-all is currently done out of convenience. I think most projects would work just as well, if groovy-all would be turned into an empty jar that just depends on the other jars. Am 22.11.2017 um

Re: Get reference to enclosing closure

Spock doesn't rewrite it to `this.getThisObject()`. This is what Spock does |with(list) {| |   SpockRuntime.verifyMethodCondition(this, "contains", [1])| |} | |The transformation from `this` to `this.getThisObject()` is done by groovy at a later stage. My guess somewhere in the

Re: Compiling groovy with java9 using maven with spring boot

Hi, its correct not to include a module-info.java, however groovy should define its Automatic-Module-Name. http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html Many other projects are already doing it, e.g., https://github.com/mockito/mockito/issues/1189 Until the fine

Re: Get reference to enclosing closure

think "this" or "getThisObject()" should really be "delegate" or "getDelegate()". *From:*Leonard Brünings [mailto:groovy-...@bruenings-it.net] *Sent:* Monday, November 20, 2017 2:27 PM *To:* dev@groovy.apache.org *Subject:* Get reference to enclosing

Re: About setting a stable module name with `Automatic-Module-Name` entry in MANIFEST

IMHO it is incorrect to have two different modules for normal and indy, otherwise they are not interchangeable. You can't have both on the classpath/modulepath anyway, since split packages are forbidden. Fatjars are not really compatible with Automatic-Module-Names, since they can't export

Get reference to enclosing closure

Hi, I'm Leonard from the Spock framework team. Guillaume suggested that I write to the dev-list with this problem. Some context: Spock has a method `with(Object, Closure)` in its Specification class that sets the object as the delegate of the closure and transforms, every call inside the

Re: Get reference to enclosing closure

ll work forever though. In the future there might be no closure class anymore. Oh and if I got you wrong, and you want a reference to the enclosing context, that would be the owner: def x = this def c = { return {owner}} assert c()() == c assert c.owner == x bye Jochen On 20.11.2017 21:27, Leonar

Re: Get reference to enclosing closure

ieb Jochen Theodorou: On 21.11.2017 21:43, Leonard Brünings wrote: Hi Jochen, your first suggestion might do the trick and if closures disappear then there will be much more that doesn't work. We currently do something like this:    public void replaceImplicitThis(Expression

Re: [VOTE] Automatic module names

+1 with the amendment from Rémi Am 03.12.2017 um 11:39 schrieb Remi Forax: > Cedric, > you can not have a dash in the name if you want the module name be > referenced in a module-info.java . > > so it should be org.apache.groovy.json > > cheers, > Rémi > > > On December

collectFilesRecurse

There is currently no good way to recursively scan through a directory-structure and collect files/results. File.eachFileRecurse and all of the overloads and derivatives don't return a result, and thus makes it awkward to use in a streaming fashion. One needs to create an external container and

Re: Get reference to enclosing closure

, but it blows up with gradle. cheers Leonard Am 22.11.2017 um 09:17 schrieb Jochen Theodorou: > > > Am 22.11.2017 um 02:11 schrieb Leonard Brünings: >> Great now I run into another problem, spock uses groovy-all, which >> repackages asm. >> The BytecodeExpression has a Me

2.5.3 breaks Spock delayed $spock_initializeFields for final fields

Hi, it seems that 2.5.3 introduced some additional checks that causes these exceptions: |java.lang.IllegalAccessError: Update to static final field spock.util.concurrent.PollingConditionsSpec.$const$0 attempted from a different method (__$swapInit) than the initializer method at

Proposal groovy-bom

Hi, the switch to fine grained artifacts with groovy-2.5 made it harder to consistently mange package versions. Many projects offer a bom pom (https://www.baeldung.com/spring-maven-bom), that manages all the packages so users of maven have to just import the bom pom instead of having to manage

Re: Proposal groovy-bom

: > On 17.09.2018 02:44, Leonard Brünings wrote: >> Hi, >> >> the switch to fine grained artifacts with groovy-2.5 made it harder >> to consistently mange package versions. >> >> Many projects offer a bom pom >> (https://www.baeldung.com/spring-maven-bom), that

Re: Proposal groovy-bom

add another project it is possible to add the > dependencyManagement section into groovy-all and remove the version in > the normal dependencies block. > > cheers > > Leonard > > > Am 17.09.2018 um 20:42 schrieb Jochen Theodorou: > > On

Re: [PROPOSAL]Support conditional return

Hi, just to throw it out there. As far as I understand this, we want to be able to return based on the value of computed by a function without having to assign the value to a variable first. Another potentially more powerful alternative would be if we could return the method from inside a

Re: switch destructuring

Hi, this is Brian Goetz initial idea https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html And these are the related JEPs https://openjdk.java.net/jeps/361 https://openjdk.java.net/jeps/375 and this is the umbrella project amber https://openjdk.java.net/projects/amber/ cheers - Leo

Groovy Console AstNodeToScriptAdapter improvements

Hi, recently Björn Kautler and I worked on a feature to test Spocks AST transforms by transpiling the resulting AST back to source. We based it off the groovy-console code, but had to fix some bugs and improve insufficient rendering. Here is the PR for Spock if you are interested in taking a

@DelegatesTo for Closures used in annotations

It is possible to define Closures for annotations, e.g., Spock's `@Requires({ os.windows })`. However, it is currently impossible to tell the IDE what this annotation will delegate to, as @DelegatesTo is only applicable for parameters. Could we either allow @DelegatesTo for TYPE_USE or mabe add a