Re: Master builds

Another way I've seen done is to execute "git rev-parse HEAD" in a custom Gradle task and dump the result into a resource file (similar to how Groovy provides the version info today). But using Grgit/JGit is better since it will work without the assumption that git is on your path. -Keegan On

Re: [VOTE] Release Groovy 2.4.8

It looks like it's there for the downloadWrapper task (wrapper.gradle). But I'm not sure why we have that defined. I've always just used gradle-wrapper.properties and "gradlew wrapper" to update the wrapper jar and gradlew scripts. If we don't need it anymore, I say we remove both the property

Re: Groovy 2.5.0-beta-1 release

+1 I checked signature of binary zip and ran a Gradle check. On Fri, Jun 2, 2017 at 12:02 PM, Daniel Sun wrote: > +1 > > Cheers, > Daniel.Sun > > > > -- > View this message in context: http://groovy.329449.n5. >

Re: Bash feature is Shell script

I've noticed this with the Alpine Docker images I maintain. GROOVY-7906 documents this. What I've done for now is replace the shebang with Bash in the scripts. Longer term, I'm thinking it'd be best

Re: Groovy 2.5.0-rc-2 breaks Gant

ake use of >> the Commons-CLI parser class. We could modify CliBuilder to silently >> ignore the specified parser. (We’d have to rename the picocli ParserSpec >> `parser` property in CliBuilder to something else.) >> >> Thoughts? >> >> >> On

Re: Groovy 2.5.0-rc-2 breaks Gant

CliBuilder in the translations list). >>> >>> For 2.5, we don't have the package translation in place and don't intend >>> to. Because of that, the point of the delegation version is to aid in >>> migration. >>> Maybe it was too big a jump to try to de

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

I don't have strong feelings on it, but I think I'd lean against it since we've already released artifacts under the 2.6 banner. 1. It can be confusing when looking in somewhere like Maven Central that the already released 2.6 artifacts are in the same line as 2.9 (one might conclude

Re: Troubles with IDEA setup

I'm with Russel: I've seen some flakiness with Gradle Idea plugin. On my current client's project I actually saw Gradle Idea plugin add the wrong version of a dependency to the project, but IntelliJ's import chose the version that was mentioned in the Gradle file. That did it for me -- I

Re: Groovy 2.5.0-rc-2 breaks Gant

ler error than silently ignoring such options. > > It's hard to tell how many people would be impacted by this, but if we > want 2.5 to be compatible with 2.4 we cannot make picocli the default in > 2.5. > > > > On Thu, May 10, 2018 at 8:42 AM, Keegan Witt <keeganw.

MissingMethodException Date.format() in GroovyDoc root template

Have we made any breaking changes to GroovyDoc? The GroovyDoc root template is failing to find a GDK method now, but I'm not seeing what changed. Using the same template in a console works new groovy.text.GStringTemplateEngine().createTemplate("${new

Re: MissingMethodException Date.format() in GroovyDoc root template

We should make the change to remove that dependency in both 2.6 and 3.0, right? On Tue, Jun 12, 2018 at 11:49 PM Keegan Witt wrote: > Ah. Thank you. That's what I was missing. > > On Tue, Jun 12, 2018 at 1:31 AM Paul King wrote: > >> You might need to add groovy-dateutil de

Re: MissingMethodException Date.format() in GroovyDoc root template

ll be there. > > On Wed, Jun 13, 2018 at 2:01 PM, Keegan Witt wrote: > >> We should make the change to remove that dependency in both 2.6 and 3.0, >> right? >> >> On Tue, Jun 12, 2018 at 11:49 PM Keegan Witt >> wrote: >> >>> Ah. Thank you.

Re: Old bytecode targets

Would it make sense then to add that as a compiler argument instead of relying on bytecode version? From a user's perspective, that relationship isn't clear. On Mon, Sep 3, 2018 at 4:34 PM Jochen Theodorou wrote: > On 03.09.2018 14:33, Keegan Witt wrote: > > I'm working on adding J

Old bytecode targets

I'm working on adding Java 9, 10, and 11 bytecodes to the 2.5 branch, and 9, 10, and 11 bytecodes when using invokedynamic to master, when I noticed we allow the targets to go back quite a ways. Should we continue to let the Groovy compiler target Java 4, 5, 6, and 7 in master, given that master

Re: Old bytecode targets

gt; On Mon, Sep 3, 2018 at 10:33 PM Keegan Witt wrote: > >> I'm working on adding Java 9, 10, and 11 bytecodes to the 2.5 branch, and >> 9, 10, and 11 bytecodes when using invokedynamic to master, when I noticed >> we allow the targets to go back quite a ways. >> >&g

Re: [VOTE] Move the Groovy repositories on git-wip-us.apache.org to gitbox.apache.org

+1 Also, folks should just be able to do "git remote add" instead of re-cloning. Shouldn't be a big deal. On Sat, Dec 8, 2018 at 4:54 PM Paul King wrote: > As per DanielG's attached email, we need to move our remaining git-wip > repos: > Apache Groovy > Repository name:Description:Last

Re: Welcome Daniel Sun to Apache Groovy PMC

Congrats Daniel, you've earned it. -Keegan On Wed, May 8, 2019, 5:58 PM John Wagenleitner wrote: > This is great news, welcome Daniel! > > On Mon, May 6, 2019 at 4:15 AM Paul King wrote: > >> >> The Apache Groovy PMC has invited Daniel Sun to join the PMC and he has >> accepted. You all

Stub constructor selection (related to GROOVY-9777)

Related to https://issues.apache.org/jira/browse/GROOVY-9777 that was noticed by someone last week, I'm thinking JavaStubGenerator.selectAccessibleConstructorFromSuper should select the closest matching parent constructor related to the number and type of parameters in the child. The code has a

Docker image user home, permissions, and volumes

An issue recently came up (https://github.com/groovy/docker-groovy/issues/61) where it was necessary to run the container with a certain uid/gid so that the container would have access to a mounted volume. Because Grapes will normally try to download into the user's home, this was a problem since

Re: More inclusive naming

I've been reticent on this because I'm more pragmatic than political. Please don't interpret this as belittling any particular position, I just prefer to view this issue primarily through the lens of a pragmatic technologist for this discussion (to the extent possible). For discussions over

Re: [PROPOSAL]Support conditional return

> Second, WRT the syntax of Kotlin, it mixes the expressions and statements. But Groovy extends the design of Java, which does not support the mixing. I wasn't saying we should support that because Kotlin does. I'm saying because we *won't* support both usages, it makes it feel more out of

Re: [PROPOSAL]Support conditional return

For context, here's a summary of a discussion we had outside this thread. Like MG, I mostly use multiple returns for early bailouts of the method, and only occasionally otherwise where it adds additional readability. I don't find the standard Java-like syntax for your use case overly-cumbersome,