Re: Mastodon presence for Apache Groovy

> > Speaking of which -- do you know of any good tools to do a sort of a > multicast to twitter and mastodon? > > You can use https://crossposter.masto.donte.com.br/ But we aware that such tools are not super well appreciated from the Mastodon community (original contents is better).

Re: Welcome Remko Popma to the Apache Groovy PMC!

Welcome, Remko! Le mer. 13 juil. 2022 à 09:31, Guillaume Laforge a écrit : > Welcome and congrats! > > On Wed, Jul 13, 2022 at 9:16 AM Mario Garcia wrote: > >> Good news! Congratulations Remko! >> >> El mié, 13 jul 2022 a las 8:59, Paul King () >> escribió: >> >>> Remko Popma has been voted as

Build up-to-date/caching is broken!

Hi folks, It seems that since last time I updated the build, caching is broken: if you run the same build twice, it's not fetching compileGroovy from cache, which it should. If you update the build, please make sure that you don't break caching by: - running the same command twice in a row and

Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3

your own key server mirror. > Or perhaps there is a way I haven't discovered yet. > > Cheers, Paul. > > > On Tue, Apr 13, 2021 at 8:00 PM Cédric Champeau > wrote: > >> Technically it's not Gradle's dependency verification which is flaky, >> it's the key serve

Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3

Technically it's not Gradle's dependency verification which is flaky, it's the key servers. That's why you must, from time to time, update the local keyring, using `--export-keys` as explained in https://docs.gradle.org/current/userguide/dependency_verification.html#sec:local-keyring Then the

Re: build changes

Hi folks, "clean" shouldn't be necessary, it's Gradle after all ;) However, `clean` won't delete the old "target" directories so something like: find . -type d -name "target" -exec rm -rf {} \; should do. Le ven. 9 oct. 2020 à 14:45, Paul King a écrit : > Another recommendation is run the

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

Congrats on having the first alpha, team! I'm just re-instantiating that because of the coordinates change, it would really be great if you could leverage Gradle Module Metadata so that users are aware of a conflict, and that Gradle can take care of it. This is basically about saying that

Re: More inclusive naming

+1 Le jeu. 11 juin 2020 à 16:56, Jeff Beck a écrit : > I find those aliases easier to understand. So I think it's a great > improvement. > > Jeff > > On Thu, Jun 11, 2020, 9:50 AM Paul King wrote: > >> Hi folks, >> >> Given recent world events, there are numerous projects that are taking >>

Re: Field order from traits

Independently of reflection or not, the compiler should be reproducible. So same sources -> same output, whatever the OS, whatever the time. This is important for trust and cache-ability. On this specific issue, the default mechanism is to use ASM which is reproducible. Le lun. 2 déc. 2019 à

Re: Upcoming releases

Just saying that using external ASM is an option now. Back then we had to repackage because ASM wasn't backwards compatible so triggered all sorts of problems when another library used it with a different version. This is not the case now since you always pass in the ASM version in the constructor

Re: [VOTE] Release Apache Groovy 3.0.0-rc-1 (take 2)

Yeah I just find it funny, when you release a "release candidate" knowing it's not a release candidate :) Le mar. 22 oct. 2019 à 17:40, Daniel.Sun a écrit : > Hi Cédric, > > > To me, it _implies_ that there will be a 3.0 rc2 for Groovy. > Yep ;-) As Paul said, one part which has only

Re: [VOTE] Release Apache Groovy 3.0.0-rc-1 (take 2)

That's a bit surprising of a release candidate, IMO. A release candidate should mean "hey if there's no bug report, that's _exactly_ that that we publish as final". Here you're saying that in any case, you're going to change the dependency to Ivy. To me, it _implies_ that there will be a 3.0 rc2

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

As the README says, you need to use the Gradle version which is declared in gradle.properties, which is 5.6.3 for this release. Le mar. 22 oct. 2019 à 11:51, Guillaume Laforge a écrit : > QQ, it's perhaps just a Gradle issue, but with the local version of Gradle > I have (Gradle 5.3.1), I can't

Re: groovy project's src/main/* folders

This is not just about Gradle, and not related to the build cache. There are different things: mixing Java and Groovy sources in a single source tree **only** makes sense for sources which are _joint compiled_. Otherwise you're just slowing down your build arbitrarily, because Groovy has to

Re: Binary compatibility fixed + Kotlin DSL

the IDE support is going to do a worst job > than someone with a lot of Groovy knowledge using the Groovy Gradle DSL. > > Sergio del Amo > > On 20 Mar 2019, at 21:50, Cédric Champeau > wrote: > > And do you honestly think that trying to hide that by not using the Kotlin > DSL

Re: Binary compatibility fixed + Kotlin DSL

And do you honestly think that trying to hide that by not using the Kotlin DSL would change anything? Le mer. 20 mars 2019 à 21:45, Sergio Del Amo a écrit : > > I do in fact see this as at least a minor threat. If Groovy itself can't > even manage to use the Gradle Groovy DSL, what hope

Binary compatibility fixed + Kotlin DSL

Hi folks, Some of you have noticed that I have fixed the binary compatibility reports on master. I also fixed checkstyle and CodeNarc, which were failing to execute. I did not, however, fixed the many errors we see when running those, nor the ones with spotbugs. It's a bit annoying because it

Re: About polish the generics type syntax for closure

I'm 100% sure a syntax like that has been discussed in the past, and discarded for different reasons: 1. consistency between using annotations and a type-checking only feature 2. what about polymorphic closures (aka closures which accept different kind of arguments) 3. the arrow syntax making it

Re: Gant is to be deleted, or will someone preserve it?

An alternative is to "archive" the project in GitHub. It's going to be read-only (see the "settings" tab). Le sam. 2 févr. 2019 à 09:46, Russel Winder a écrit : > On Sat, 2019-02-02 at 09:18 +0100, Guillaume Laforge wrote: > > Why deleting it? > > Keep it for posterity! :-) > > Someone, or some

Re: About the lazy consensus on Pull Requests

I agree that no "big change" should be merged without review. 72h may sound a lot, but it's not. Le dim. 27 janv. 2019 à 22:01, Daniel.Sun a écrit : > I agree with you on most of your opinions, but some of them are a bit ideal > for an open source project such as Apache Groovy IMHO. I feel

Re: [PROPOSAL]Provide an option to generate stubs in in-momery file system for better compiling performance

It's an interesting idea. I like that it's hidden behind a flag, because sometimes you want to keep the stubs. That must be the case for IDEs that implement "some kind" of incremental compilation. Le ven. 18 janv. 2019 à 09:44, Daniel Sun a écrit : > Hi all, > > [Background] >Groovy's

Re: [PROPOSAL]About creating open collective for Groovy programming language in the name of Groovy Community

My 2 cents: as a Groovy enthusiast, I like the idea and support it. As a Groovy committer and PMC member, however, I have some things to say. First, it's not very different to have one company paying one developer full time to develop Groovy and contribute features than it is to have a collective

Re: [VOTE] Release Apache Groovy 2.5.5

+1 Le dim. 23 déc. 2018 à 03:20, John Wagenleitner a écrit : > +1 (binding) > > On Thu, Dec 20, 2018 at 4:28 PM Paul King wrote: > >> >> Dear development community, >> >> I am happy to start the VOTE thread for a Groovy 2.5.5 release! >> >> This release includes 20 bug fixes/improvements as

Re: [VOTE] Release Apache Groovy 2.4.16

No time yet, I'll check tonight if I find time. Le mer. 12 déc. 2018 à 14:39, Paul King a écrit : > Still needing one more vote on this release. Anyone got time to check? > > On Sun, Dec 9, 2018 at 9:59 PM Paul King wrote: > >> >> Dear development community, >> >> I am happy to start the VOTE

Re: About downgrading gradle to 4.10.3 on master

The fix is not to use the internal APIs and rely on the "maven-publish" plugin instead. Due to historical reasons, our publishing is a bit of a mess, to say the least, so I was reluctant on changing it to avoid breakages when publishing. One of the issues is that with our current publishing

Re: About downgrading gradle to 4.10.3 on master

It's not really surprising, the build has been using internal APIs for years, I'm surprised it didn't break earlier :) Le mar. 11 déc. 2018 à 17:08, Andres Almiray a écrit : > Hi Daniel, > > Can the failure be reproduced locally or is it. TeamCity specific issue? > > Best > Andres > > Sent from

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

+1 you can use git remote seturl to avoid cloning again. Le dim. 9 déc. 2018 à 05:52, John Wagenleitner a écrit : > +1 > > On Sat, Dec 8, 2018, 1:54 PM Paul King >> As per DanielG's attached email, we need to move our remaining git-wip >> repos: >> Apache Groovy >> Repository

Re: About the enhanced version of `Properties`, i.e. `GProperties`

+1 to using a different file extension for gproperties Le mar. 6 nov. 2018 à 11:32, Daniil Ovchinnikov < daniil.ovchinni...@jetbrains.com> a écrit : > we can not replace Properties in existing groovy > code easily because we have to change the file extension > > > Exactly this. > > Also please

Can we get rid of illegal reflective access operation warnings?

Hi, It's long overdue, but the status quo is not really nice. Running Groovy on Java 9+ gives warnings like this: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1

Re: [VOTE] Release Apache Groovy 2.5.3 (take 2)

ory >> should fix it. >> >> On Fri, Oct 12, 2018 at 1:05 AM Cédric Champeau < >> cedric.champ...@gmail.com> wrote: >> >>> At this point, -1. See below. >>> >>> $ gpg --verify apache-groovy-src-2.5.3.zip.asc >>> gpg

Re: [VOTE] Release Apache Groovy 2.5.3 (take 2)

of people in the world: Those who understand binary, > and those who don't. > To understand recursion, we must first understand recursion. > > > On Fri, Oct 12, 2018 at 8:05 AM Cédric Champeau > wrote: > >> At this point, -1. See below. >> >> $ gpg --verify apache

Re: [VOTE] Release Apache Groovy 2.5.3 (take 2)

At this point, -1. See below. $ gpg --verify apache-groovy-src-2.5.3.zip.asc gpg: assuming signed data in 'apache-groovy-src-2.5.3.zip' gpg: Signature made Thu 11 Oct 2018 07:34:42 AM CEST gpg:using RSA key 6A65176A0FB1CD0B gpg: Good signature from "Paul King " [unknown] gpg:

Re: Capturing GEPs better

This is typically what should live at groovy.apache.org :) Le jeu. 11 oct. 2018 à 16:54, Guillaume Laforge a écrit : > +1 > I like the idea of having GEPs on the wiki side of the site. > > Le jeu. 11 oct. 2018 à 15:35, Paul King a écrit : > >> This is an example of what I had in mind: >>

Re: Proposal groovy-bom

Moving from the `dependencies` to `dependencyManagement` block is not semantically equivalent. In the `dependencies` block you get all the dependencies transitively, meaning that if you request groovy-all, you'd get all the individual modules. If it's moved to `` then you only get

Re: About type inference of method return value

Sorry I don't understand what you are saying. What I'm saying is that we already had such an implementation, and we decided to _remove_ it. Are you saying that you have a branch that reintroduces it, or that it's already on master? I disagree with the statement that the "users require smarter

Re: About type inference of method return value

Hi Daniel, We discussed this when we implemented static compilation in the past. There were 2 different relates cases discussed: - smarter type inference for final fields - smarter type inference for final methods and decided not to implement them, so that it's not confusing for users when the

Re: [VOTE] Release Apache Groovy 2.5.2

+1 Le lun. 13 août 2018 à 10:09, Jochen Theodorou a écrit : > +1 > > Am 10.08.2018 um 18:57 schrieb Paul King: > > Dear development community, > > > > I am happy to start the VOTE thread for a Groovy 2.5.2 release! > > > > This release includes 20 bug fixes/improvements as outlined in the > >

Re: Gradle build logs

The message explains how you can make the choice persistent, and yes, CI is exempt. Le ven. 8 juin 2018 à 14:43, Russel Winder a écrit : > On Thu, 2018-06-07 at 13:20 +0200, Cédric Champeau wrote: > > I have added an explicit opt-in :) > > > > I believe

Re: Gradle build logs

I have added an explicit opt-in :) Le jeu. 7 juin 2018 à 12:39, Cédric Champeau a écrit : > Well, currently there's no way to tell that you don't want to expose > _some_ of the data, so you need to opt-in (which is, AFAIK, GDPR compliant, > see https://gradle.com/legal/privacy). Th

Re: Gradle build logs

we should at least ask once. Le jeu. 7 juin 2018 à 12:26, Russel Winder a écrit : > On Thu, 2018-06-07 at 12:12 +0200, Cédric Champeau wrote: > > I think you're right: currently the build uses `publishAlways()` and has > > license accept enabled, but it should be per per

Re: Gradle build logs

I think you're right: currently the build uses `publishAlways()` and has license accept enabled, but it should be per person. Le jeu. 7 juin 2018 à 12:09, Russel Winder a écrit : > Cédric, > > > I wonder if the Infrastructure section of the Gradle build log every Groovy > build submits to

Re: Groovy build with Gradle 4.8

\o/ Le jeu. 7 juin 2018 à 11:50, Russel Winder a écrit : > I think I lost an email, but I recollect Daniel asked me to build of Groovy > master/HEAD with the new 4.8 Gradle. Tried it, seems to work fine. But it > is > now a matter of official record: > > https://gradle.com/s/eqtdqjr3nlagi > >

Re: [ANNOUNCE] Apache Groovy 2.5.0 released

Congrats to anyone involved in that long awaited release! Le mer. 30 mai 2018 à 08:37, Paul King a écrit : > Dear community, > > The Apache Groovy team is pleased to announce version 2.5.0 of Apache > Groovy! > Apache Groovy is a multi-facet programming language for the JVM. > Further details

Re: Groovy 2.5 @Macro ?

It could very well be a packaging bug: if the macro transformation descriptor is not on class path, it won't work. I'm on my phone now so I can't check, but it would explain. Le dim. 27 mai 2018 à 18:47, mg a écrit : > I saw that, but assertScript is used for many tests,

Re: Performance of the compiler

e we talking about here ? > > Cheers, > mg > > > Ursprüngliche Nachricht > Von: Cédric Champeau <cchamp...@apache.org> > Datum: 24.05.18 08:30 (GMT+01:00) > An: dev@groovy.apache.org > Betreff: Performance of the compiler > >

Re: Performance of the compiler

The problem is not the performance of the test, it's the performance of _compiling_ the test. @CompileStatic wouldn't help there. Le ven. 25 mai 2018 à 14:24, Thibault Kruse a écrit : > Would the test performance be improved if @CompileStatic were used? I > think

Re: Performance of the compiler

e > parsing instead of rolling it ourselves). > > > > JPMS would naturally make complicate things further, but again, ECJ has > cracked this, too. > > > > -Jesper > > > >> On 24 May 2018, at 08.30, Cédric Champeau <cchamp...@apache.org> wrote: >

Re: upcoming 2.5.0 release

I realize I have pushed the groovydoc improvements to 2_5_X. This means the branch differs from the last rc. Does it mean it's going to be in 2.5.1, or that the final 2.5.0 is going to be different from the rc2 (uh!) or, that we need rc3? Le ven. 25 mai 2018 à 10:53, Paul King

Re: Performance of the compiler

Be warned that caching may prove to be complicated: what if a class in the same compile unit is named `List`, or a class in the same package? This is one of the reasons the lookup is not cached for this. Le ven. 25 mai 2018 à 10:17, Daniel.Sun a écrit : > I am going to cache

Performance of the compiler

Hi folks, I just wanted to share the result of profiling the performance of the compiler on "real world" classes, namely compiling the tests of Gradle. We have a lot of tests, so compilation times becomes really a pain point, so I have checked where we spend time. I have attached the export of

Re: Troubles with IDEA setup

run DownUpStepTest I'm seeing the same symptoms as you are - stuck in > "Groovyc: semantic analysis [tests of groovy-xml and 8 more]" with CPU is > not busy. > > For reference, I'm using IntelliJ 2018.1 181.4203.550. > > On Tue, May 22, 2018 at 8:02 PM, Cédric Champeau < >

Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]

+1, regarding indy by default, I wonder if we could provide the "old" MOP as a backward compatibility runtime jar... Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller a écrit : > > > On 23 May 2018, at 12.23, Russel Winder wrote: > > > > On Wed,

Re: Possible bug in AstBuilder Antlr4

thanks! Le mer. 23 mai 2018 à 09:48, Daniel.Sun a écrit : > It is fixed: > > https://github.com/apache/groovy/commit/a26c190f9a70b0c430004d80c56e37703c2edfe8 > > Cheers, > Daniel.Sun > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >

Re: Possible bug in AstBuilder Antlr4

It cannot. However the GString templates look like scripts, which is why I added an import in the first place. But then the builder fails with a ClassCastException. I would have expected it to fail with a better error message in this case, like "You're not allowed to use an import in a method

Re: Troubles with IDEA setup

That's what I meant with "native import". Le mer. 23 mai 2018 à 08:28, Daniel.Sun a écrit : > Hi Cédric, > >Try to import as a gradle project? > > Cheers, > Daniel.Sun > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >

Re: Troubles with IDEA setup

I managed to do something using the IDE native import (instead of using ./gradlew idea) and delegating all actions to Gradle. It's slower feedback, but at least I can work. Le mar. 22 mai 2018 à 23:37, Cédric Champeau <cedric.champ...@gmail.com> a écrit : > No luck, I'm still stuck :( &

Re: Troubles with IDEA setup

No luck, I'm still stuck :( Le mar. 22 mai 2018 à 21:23, Daniel.Sun a écrit : > Hi Cédric, > > It's OK on my machine. > > Usually I run `gradlew clean bootstrapJar --no-build-cache` before > running tests via IDEA. > > Good luck. > > Cheers, > Daniel.Sun > >

Troubles with IDEA setup

Hi team, I've been trying to figure out what is happening for hours now, but I cannot find any reason. I'm working on master, after removing all IDEA state (.iml, .ipr, .iws), regenerating the IDEA files using: ./gradlew jar idea --rerun-tasks And then I open the project in IDEA and try to run

Re: 2.5.0-rc-3

Yeah. Doesn't prevent us from having a quick 4.0 with module revamp if we're extremely good :) Le mar. 22 mai 2018 à 13:29, Jesper Steen Møller <jes...@selskabet.org> a écrit : > And postpone module revamp? > > -Jesper > > On 22 May 2018, at 13.27, Cédric Champeau <c

Re: 2.5.0-rc-3

I think we should slim down what Groovy 3 is, make it Parrot + JDK 8 basically. Le mar. 22 mai 2018 à 13:22, Paul King a écrit : > The question is really (most of) Parrot on JDK7+ or Parrot on JDK8+ sooner. > > > On Tue, May 22, 2018 at 7:55 PM, Daniel.Sun

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

2.99 or alike doesn't make sense. What if you have to release a bug fix release. 2.99.1? That's nasty :) I'm very much in favor of dropping 2.6 altogether because it's confusing as possible. We don't have 2.5 yet, and we already have alphas for 3.0. This mean we would live with 3 "live" branches

Re: [DISCUSS] Renumber Groovy 2.6 to 2.9

+1 but alternatively, we could just skip 2.6 and go straight to 3.0. Le dim. 20 mai 2018 à 15:25, mg a écrit : > 2.9.0 could make people ask themselves where 2.6/2.7/2.8 went, whereas > 2.97 is so far from 2.5, that I think people would get that it means more > "3.0 minus

Re: About raw string and enhanced try-with-resource

+1 for both. In particular I like that you can choose your own delimiter in Java 11 raw strings. 2018-05-15 12:48 GMT+02:00 Jesper Steen Møller : > On 15 May 2018, at 12.31, Paolo Di Tommaso > wrote: > > > No. There's an important difference: raw

Re: What the... static compile by default

Hi Daniel and sorry you are "tired". Maybe the tone I used was inappropriate?, but it wasn't directed at you personally. I'm quite surprised to see some things like that happening on master without any discussion on the MLs. Maybe that's because I expect too much from the developers of Groovy, but

What the... static compile by default

Hi folks, Sorry to be the bad cop again, but when the heck did this land into core: https://github.com/apache/groovy/blob/5443e87882f9b88169876f6d043ed54b5ae9023b/src/main/java/org/codehaus/groovy/control/CompilerConfiguration.java#L943-L988 As much as I love static compilation, this should

Re: [VOTE] Release Apache Groovy 2.5.0-rc-2

+1, even though some tests are not passing, see below, I think we should take a look at them gradle -b wrapper.gradle wrapper : ok ./gradlew clean dist: ok (https://scans.gradle.com/s/c7jwthugis7b2, we seriously need to do something for the performance of Groovydoc...) ./gradlew testAll: ko

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

2018-04-10 11:52 GMT+02:00 Marcin Erdmann : > Yeah, I've noticed the zip packaging in pom but wasn't sure if that's the > reason why Gradle tries to resolve the jar for that artifact. Should I > create an issue for it? > Yes, please :) Note that Maven behaves the same

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

There's a bug in the published pom: it says zip instead of pom. We should fix this, thanks for the report! 2018-04-09 23:15 GMT+02:00 Marcin Erdmann : > Paul, > > I'm having a go at giving this release a spin by updating Geb's build to > use it but unfortunately I'm

Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-1 released

Hi Paul, Thanks for making this release. It would be nice to have _cummulative_ change log/release notes since 2.4. As they are now, the notes are pretty useless as it doesn't indicate what changes from the last major release. WDYT? 2018-04-09 8:07 GMT+02:00 Paul King : >

Re: About the Phoenix plan for Groovy

etic union/intersection types, as it's very hackish today. 2018-04-08 20:57 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>: > On 08.04.2018 20:46, Cédric Champeau wrote: > [...] > >> Honestly I don't have much time to work on Groovy. And if I had, the >> generics STC bugs wo

Re: About the Phoenix plan for Groovy

2018-04-08 19:31 GMT+02:00 Daniel.Sun : > Hi Cédric, > >At first we all admit your effort on STC is great :-) > >I usually try to use STC for better performance, but sadly I have to > turn to dynamic mode sometimes. Recently I wrote a hadoop example in Java, >

Re: Determining the registered DGM classes at runtime

2018-04-06 22:42 GMT+02:00 Jochen Theodorou : > ah sorry, I was not explaining right... > > I was going to suggest something similar to what you probably already have > found, which is StaticTypeCheckingSupport.EXTE > NSION_METHOD_CACHE.getExtensionMethods(ClassLoader) > but

Re: About the Phoenix plan for Groovy

2018-04-08 3:58 GMT+02:00 Daniel Sun : > Hi all, > > I have a plan named "Phoenix" to share. As we all know, STC is buggy, > one of reasons is that STC lacks tests during development. It's interesting you put test coverage as one reason that the STC is buggy, but

Re: Returned post for annou...@apache.org

Thanks, Paul! 2018-03-28 10:08 GMT+02:00 Paul King : > Fixed. > > On Wed, Mar 28, 2018 at 1:47 AM, Paul King wrote: > >> >> Looks like we'll have to improve how we present our download information. >> Even though the Apache release repo and bintray mirror

Re: [RFE] Methods as expressions

It's funny to see arguments about compatibility with Java here. Groovy's compatibility with Java is the promise that you can _almost_ copy and paste Java code and it compiles in Groovy. Not the other way around ;) In any case, I was doubtful as you are here before actually using it in Kotlin.

Re: [RFE] Methods as expressions

ng name) = Hello $name" > > (why did you use a return keyword in your sample ?) > > I dont see an improvement in readability here - the main "advantage" is > that curly braces are annoying to input on non-US keyboard layouts ;-) > > mg > > > > ---

Re: [RFE] Methods as expressions

any system administrator. > There are 10 types of people in the world: Those who understand binary, > and those who don't. > To understand recursion, we must first understand recursion. > > On Tue, Mar 20, 2018 at 11:41 AM, Cédric Champeau < > cedric.champ...@gmail.com>

[RFE] Methods as expressions

Hi, One of the Kotlin features I really like is the short-hand notation for simple expression methods: class Foo { fun truth(): Integer = 42 } For example, in Groovy, you write: @Controller("/") class HelloController { @Get("/hello/{name}") String hello(String name) {

Re: [GEP]Lazy evaluation for Groovy 3

-1, I also think this is confusing. 2018-03-17 13:30 GMT+01:00 Guillaume Laforge : > I also find it confusing, in particular because it's not obvious, and > there's some redundancy already with @Lazy (and Paolo has a good point as > well as using closures are somewhat of a

Re: Stop maintaining 2.4.x?

I don't think calling it 3.0-jdk7 is a good thing to do: the runtime would be different, with different bugs. Plus, it would add confusion on some build tools, with random dependencies on jdk7, or indy, or ... I think we should focus on getting 2.5 out, and then go with 3.0 asap. 2018-03-12

Re: Stop maintaining 2.4.x?

I do. It's long overdue that 2.5 should be out. By working on 4 (!) different branches, we just can't manage to publish 2.5, this is a shame. 2018-03-11 15:23 GMT+01:00 Mauro Molinari <mauro...@tiscali.it>: > Il 11/03/2018 15:12, Cédric Champeau ha scritto: > >> Hi folks, &

Stop maintaining 2.4.x?

Hi folks, I'm wondering if it's reasonable to continue maintaining 2.4.x. We have a long standing 2.5 release waiting, as well as 2.6 and master. Given the number of maintainers we have, I feel it's just slowing us down, and we need to move forward. Honestly I'd be in favor of only maintaining 2

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

You have to be aware that this java syntax prepares the way for pattern matching. I think we need to wait and see before doing it. Le 1 mars 2018 17:45, "Paolo Di Tommaso" a écrit : > I agree that groovy should continue to be compatible with java syntax as > long as

Re: [VOTE] Release Groovy 2.5.0-beta-3

+1 (binding). Build successful: https://scans.gradle.com/s/raolpvm3dk5cm Checksum ok: > cat apache-groovy-src-2.5.0-beta-3.zip.sha256 700541e2c94f131f69d5ad3e9099819fc6375b84770d89539aee4a5e6fd636db > sha256sum -b apache-groovy-src-2.5.0-beta-3.zip

Re: Groovy plugin for Eclipse 2.9.2 has been released

Congrats, that's very important work indeed! 2018-01-09 12:32 GMT+01:00 Paul King : > +1! Nice work Eric! > > On Tue, Jan 9, 2018 at 9:11 PM, Mauro Molinari > wrote: > >> Hello all, >> I hope this message won't be considered inappropriate, but I would

Re: [VOTE]Support package scope via `package` keyword

I'd tend to be -1 on the name "package" and 0 on the feature. The -1 is because "package" is not a modifier by itself. I'd prefer "package private" (the official Java name for this). So it leads to the 0, because "package private" is kind of verbose, and doesn't save much from "PackageScope".

Re: A reminder about how things are compiled

Nope, but I see you're using JDK 9. Maybe that's the reason. 2017-12-28 17:21 GMT+01:00 Daniel Sun : > Hi Cédric, > > I imported Groovy project into IntelliJ IDEA via opening > build.gradle, > but failed to run single test via click the "Run" button. > >

Re: A reminder about how things are compiled

Yes. 2017-12-27 14:24 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>: > On 27.12.2017 13:59, Cédric Champeau wrote: > >> Actually I just tested with the native IntelliJ import, that is to say >> _without_ calling "gradle idea", and it just works out of the bo

Re: A reminder about how things are compiled

I think the IDE setup can be improved. I didn't take at shot at this yet. 2017-12-27 13:22 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>: > On 27.12.2017 10:04, Cédric Champeau wrote: > [...] > >> The consequence, however, is that any change to a Java class in Groovy >&g

A reminder about how things are compiled

Hi fellow Groovy contributors! Given the recent question from Jochen about how to only execute tests from the "core" project when you "know you only modified core" triggering re-execution of tests for all modules, let me explain why this is like this. Groovy is partially written in Groovy. It

Re: Why no asm6 on Groovy2.4.x?

FTR it's pretty easy to find out what brings the faulty dependency by accessing the build scan: https://scans.gradle.com/s/lz5mbozdytxtc/dependencies?dependencies=asm-all 2017-12-26 10:45 GMT+01:00 Jochen Theodorou : > On 26.12.2017 00:54, Daniel.Sun wrote: > >> Hi Jochen, >>

Re: Why no asm6 on Groovy2.4.x?

There's no such thing as asm-all. Just like us, they had to get rid of their "all" artifact in 6.0. So we have to use the normal version. Le 26 déc. 2017 00:54, "Daniel.Sun" a écrit : > Hi Jochen, > > It seems that Groovy does not rely on asm-all: >

Re: Gradle build updates

Just run :subprojectname:test Le 23 déc. 2017 1:13 PM, "Jochen Theodorou" a écrit : > hi all, > > is there an easy way to execute only the tests of the main module and not > of any sub-module? I am asking because for development it was for me first > stage to get the tests

Re: Keeping DGM helper methods?

+1 2017-12-12 17:42 GMT+01:00 Jochen Theodorou : > Hi all, > > > If we all agree on using only Indy in Groovy 3, we could get rid of all > the DGM helper methods. What do you guys think? > > bye Jochen >

Re: Building Groovy

> > > I disagree. 99% of our users don't even know what call site caching is. > They don't know what invokedynamic means, > > > You think that 99% of Java professionals do not know what a feature that > has been around since Java 7 is ? > And even if that was the case: Google "java invoke dynamic"

Re: [GitHub] groovy pull request #:

Don't forget that there's the build cache now. Look at the build scans to check what was avoided. Le 19 déc. 2017 6:29 PM, "paulk-asert" a écrit : > Github user paulk-asert commented on the pull request: > >

Re: Building Groovy

2017-12-19 2:21 GMT+01:00 MG : > Hmmm, I don't know if Paul has some comeback, but to me you make a very > convincing point... > In that case the best way forward to me seems to be to > 1) Ask non-@CompileStatic Groovy users who can afford the time to switch > to the invoke

Re: Gradle build updates

No there is not. But it should be pretty easy to do so, using Gradle shadow plugin for example. 2017-12-18 16:59 GMT+01:00 : > "The "all" sources is still produced. But there's no all jar anymore." > > > > Is there a way to get back to being able to produce an all

Re: Gradle build updates

Alright folks, I have completed most of what I wanted to do. The performance of the build is now much better. I have backported everything to the 2.5 and 2.6 branches, and also updated CI. > So is it still possible to produce the groovy-all.jar and groovy-all-sources.jar from the SDK zip? The

Re: CC and build revision

My pleasure, Russel! 2017-12-15 10:52 GMT+01:00 Russel Winder : > Thanks to Cédric for his time spent revising the Groovy build system. It is > now much easier and simpler to build Groovy HEAD. > > I guess I am now under pressure to get GPars 2 out so Groovy can have a >

  1   2   3   >