Re: This was a surprise…

This looks to be related to the recent changes by Paul for the new release process. Probably an overlook. Gradle records all Groovy builds, yes. Typically here you could have shared the URL only (and maybe clicked on it since it now shows my face instead of yours ;)) and it would tell what tasks

Welcome to our new committer : Sergei Egorov

Hi folks, I'd like to introduce you to Sergei Egorov, our new Apache Groovy committer! Some of you may already know Sergei for his work on macros, which are going to make appearance in Apache Groovy 2.5. He is a very talented developer with the skills we need to help Groovy move forward. A warm

Re: Separating the Groovy compiler and runtime?

It would definitely be a good thing to have a cleaner separation between the 2. It's not so easy to do so because of backwards compatibility issues. 2016-11-26 10:22 GMT+01:00 Tatai Márton : > Hello! > > I am trying to understand the Groovy language, and something keeps

Re: Negative relational operators for Groovy 3

I find this very hard to decipher. The fact we wonder about the semantics is a red warning to me. I wouldn't add those to the language. Le 22 nov. 2016 12:18, "Daniel Sun" a écrit : > Hi Jochen, > > According to your proposals, I'm going to add the following

Re: Negative relational operators for Groovy 3

I agree with Jochen and Guillaume: +1 to !instanceof and !in, but I don't like the other variants. 2016-11-18 14:11 GMT+01:00 Daniel Sun : > Hi Jochen, > > > I think !instanceof and !in are ok. The others... not sure here. Right > > now a*=b, which means !< is >=. And

Re: Build fail on JDK9

Interesting, I'm not sure it is related... 2016-11-17 10:52 GMT+01:00 Russel Winder <rus...@winder.org.uk>: > On Thu, 2016-11-17 at 10:49 +0100, Cédric Champeau wrote: > > yes > > Splendid. > > Except, I think I now get a different error: > > … > :groovy:jarAl

Re: Build fail on JDK9

yes 2016-11-17 10:47 GMT+01:00 Russel Winder <rus...@winder.org.uk>: > On Thu, 2016-11-17 at 09:27 +0100, Cédric Champeau wrote: > > You can run the build with -Dscan and share the link, it would give > > the > > context we need :) > > Is that as in: > >

Re: Build fail on JDK9

You can run the build with -Dscan and share the link, it would give the context we need :) 2016-11-17 9:26 GMT+01:00 Guillaume Laforge : > You always forget to give me precise details!  > JDK 9 is a very vague context! > > Le 17 nov. 2016 8:44 AM, "Russel Winder"

Re: Safe index for Groovy 3

Not throwing an NPE doesn't mean you are safe. It means it doesn't throw errors, but you gave away on semantics. NPEs are often blamed, but they correspond to developer errors. Only the developer knows if null is relevant or not. I'm totally -1 on this. 2016-11-09 16:33 GMT+01:00 OC

Re: restructuring sources

+1, I also want to restructure the Gradle build at some point. It's really inefficient as it is now. 2016-11-04 18:01 GMT+01:00 Jochen Theodorou : > Hi all, > > after playing around with the idea of having the parser in its own project > I started wondering if we should not

Re: try-with-resources statement for Groovy 3

Cool stuff. When you add such features, it is very important to double check they also work with static compilation. Keep up the good work! 2016-11-04 17:54 GMT+01:00 Daniel.Sun : > Hi Jochen, > >Thanks for your advice. I'll refactor the test cases later. > >

Re: Custom operator for Groovy 3

I'm -1 on adding custom operators. We always said we wouldn't fall into the same trap as C++ or Scala, but instead allow overriding existing operators. Le 30 oct. 2016 10:03, "Paolo Di Tommaso" a écrit : > This sounds a cool feature for DSL writers. What characters

Re: replacing jarjar by gradle shadow plugin

g possible the day before a very important release. > > Rémi > > ------ > > *De: *"Cédric Champeau" <cedric.champ...@gmail.com> > *À: *dev@groovy.apache.org > *Envoyé: *Vendredi 28 Octobre 2016 09:03:36 > *Objet: *Re: replacing jarj

Re: replacing jarjar by gradle shadow plugin

Yes, the shadow plugin is also one of the most used Gradle plugins out there. It's rock solid :) 2016-10-28 0:12 GMT+02:00 Guillaume Laforge : > Right, that's what it says on the tin: > https://github.com/johnrengelman/shadow > > On Fri, Oct 28, 2016 at 12:01 AM, Jochen

Re: [PROPOSAL]Refine the implementation of LRUCache

We still cannot do this on `master`, at least until 2.5 is out, because it's Java 7. Also things we need to consider when using external libs include how much the distribution would grow. 2016-10-26 8:27 GMT+02:00 孙 岚 : > Hi all, > > I found the LRUCache that

Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1

I would much favor letting the 2.4 branch die (aka, release 2.4.8), then make 2.5-beta and final asap, and release regular 3.0 milestones. 2016-10-20 10:29 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>: > On 20.10.2016 09:28, Cédric Champeau wrote: > >> I don't think it's

Re: getting in line for the releases of groovy 2.4.8 and 2.5.0-beta-1

I don't think it's reasonable to put the new parser in 2.5. There are too many grey areas: performance, backwards compatibility, dependencies, upgrade to Java 8... Better ship 2.5, then work hard on 3.0, even if it means delaying MOP2 to 4.0. 2016-10-20 1:52 GMT+02:00 Jochen Theodorou

Re: Lambda expression for Groovy 3

2016-10-19 10:51 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>: > > > On 19.10.2016 09:09, Cédric Champeau wrote: > >> First of all, great work, Daniel ! I'm confident that making the >> "lambdas" be "closures" in Groovy is enough. >>

Re: Lambda expression for Groovy 3

First of all, great work, Daniel ! I'm confident that making the "lambdas" be "closures" in Groovy is enough. I stated it in the past but I'm going to repeat myself here, I don't think having 2 syntax for "closures/lambdas" with slightly different semantics would help our users/language. That

Re: Proposal: Statically compileable builders

I prefer to support different _methodMissing_ methods taking different arguments, because they can participate in method selection and return a more specific type. Something to consider too: @DelegatesTo is not on par with @ClosureParams wrt to the types it can express. In particular, it doesn't

Re: Proposal: Statically compileable builders

Hi Graeme and thanks for the proposal! I think we should be very clear about the objectives here, and very clear about how to write such builders. In particular, in the past, we've explicitly discarded the idea of doing "Scala-like" dynamic in compile static mode, because the types are important.

Re: Being gobsmacked

That's correct. No need to worry, it's expected :) 2016-09-29 21:19 GMT+02:00 John Wagenleitner : > On Thu, Sep 29, 2016 at 11:17 AM, Jochen Theodorou > wrote: > >> On 29.09.2016 13:14, Russel Winder wrote: >> >>> I just noticed that Groovy 1.8.9

Re: Recent commit breaks gradle builds

Ah that's annoying. We had to do this to workaround memory leaks with Groovy and Java 7 (and the name states). This change basically means that users will start seeing errors if they upgrade Groovy. Is it on `master` or 2.4.8? I would consider this a blocker for the release. 2016-09-19 1:49

Re: Groovy build fail

The change to setAccessible that Jochen is talking about is indeed a big problem. It breaks Gradle too, in various ways. I'm not even sure we can fix it while maintaining the same level of functionality. 2016-09-24 17:11 GMT+02:00 Russel Winder : > On Sat, 2016-09-24 at

Re: TeamCity back on track

The elephant i see is that now that IBM (and Google is around the corner) > uses the OpenJDK, the OpenJDK implementation becomes the defacto standard > so recent 3rd party libraries tend to use OpenJDK specifics in their > implementation. Before, it was less an issue because there was multiple >

Re: TeamCity back on track

:00 Jochen Theodorou <blackd...@gmx.org>: > On 18.09.2016 15:03, Remi Forax wrote: > >> >> >> -------- >> >> *De: *"Cédric Champeau" <cedric.champ...@gmail.com> >> *À

Re: TeamCity back on track

Dimanche 18 Septembre 2016 12:31:56 > > Objet: Re: TeamCity back on track > > > On 18.09.2016 10:47, Cédric Champeau wrote: > >> I just installed Jigsaw b136. Let me know if it helps. > > > > looks like gradle has a problem with this one as well > > > > bye Jochen >

Re: Status of CI builds for pull requests

We can't use TeamCity for pull requests, for security reasons. I'm not sure why the Travis build failed with such an error... 2016-09-08 14:37 GMT+02:00 Graeme Rocher : > Hi all, > > The jenkins build seems to be disabled and the Travis build is failing for > a reason

Re: JDK 9 Jigsaw builds

Yeah, I found why it passed in my local build: my ~/.gradle/gradle.properties file has higher priority. 2016-07-15 17:45 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>: > On 15.07.2016 17:34, Cédric Champeau wrote: > >> Can you try removing the `-XX:MaxPermSize

Re: JDK 9 Jigsaw builds

n 15.07.2016 17:12, Cédric Champeau wrote: >> [...] >> >>> I'm just doing this: >>> >>> JAVA_HOME=/opt/jdk1.9.0-jigsaw gw -Dscan --continue --parallel test >>> >> > > Unrecognized VM option 'MaxPermSize=384m' > Error: Could not create the

Re: JDK 9 Jigsaw builds

Are you running with the wrapper? ./gradlew ... 2016-07-15 17:18 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>: > On 15.07.2016 17:17, Jochen Theodorou wrote: > >> On 15.07.2016 17:12, Cédric Champeau wrote: >> [...] >> >>> I'm just doing this: >>&

Re: JDK 9 Jigsaw builds

So I managed to get the `groovy-xml` module build pass and test with Jigsaw. It requires the latest snapshot of Gradle, and confirms that using `-release` instead of {`-source`, `-target`, `-addmods`} work. There's a big drawback with using `-release` though. Typically `groovy-core` uses the API

Re: JDK 9 Jigsaw builds

The option is `-addmods java.xml.bind` 2016-07-07 12:56 GMT+02:00 Russel Winder : > On Thu, 2016-07-07 at 07:44 +0200, Jochen Theodorou wrote: > > On 06.07.2016 20:00, John Wagenleitner wrote: > > > [...]In order to get the latest > > > jdk-9 snapshot build to run locally I

Re: The Build

Thanks, yes, I saw this. I think we might need an addExport for JAXB but I didn't have time to take a closer look. 2016-06-29 7:51 GMT+02:00 Russel Winder : > Great to see the upgrade to Gradle 3, now it is feasible to build on > JDK9. Nice one Cédric. > > However the build

Re: [20160619]Progress on the new parser for Groovy

Excellent work, guys! 2016-06-19 10:33 GMT+02:00 ? ? : > Hi Groovy-Dev, > > The new parser for groovy has reached another milestone, it now can > handle almost > all source code of Groovy in Action 2nd Edition(*612 pass **/ 613 total*), all > source code of

[RESULT] [VOTE] Release Apache Groovy 2.4.7

Hi all, The vote for releasing Apache Groovy 2.4.7 has passed: - 9 +1 votes (5 binding) - 0 neutral vote - 0 negative vote Vote thread: https://mail-archives.apache.org/mod_mbox/groovy-dev/201606.mbox/%3CCADQzvmkixhBk_Hi%3Dpn64S6qnkuG85%2BBA0GN%2B4XR91OHjdv_Hdw%40mail.gmail.com%3E As such, I'm

[VOTE] Release Apache Groovy 2.4.7

Dear community, I am happy to start the VOTE thread for the long awaited Apache Groovy 2.4.7! This release includes numerous bugfixes for which list can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12334898 Tag:

Re: 2.4.7 Release?

No, because that's against the Apache policy: releases *must* be voted, and that's a human process. > Kind regards, > Nick > > On Wed, 25 May 2016 05:46 Cédric Champeau <cedric.champ...@gmail.com> > wrote: > >> I'll do it. >> >> 2016-05-21 6:43 GMT+02:00 And

Re: 2.4.7 Release?

; On Fri, May 20, 2016 at 7:33 AM, Cédric Champeau < > cedric.champ...@gmail.com> wrote: > >> We can't. There are rules, now :) >> >> 2016-05-20 16:31 GMT+02:00 Søren Berg Glasius <soe...@glasius.dk>: >> >>> Live releasing at GR8Conf ! ;) That'

Re: 2.4.7 Release?

44 91 88, Skype: sbglasius > --- Press ESC once to quit - twice to save the changes. > > From: Cédric Champeau <cedric.champ...@gmail.com> > <cedric.champ...@gmail.com> > Reply: dev@groovy.apache.org <dev@groovy.apache.org> > <dev@groovy.apache.org&

Re: 2.4.7 Release?

May 20, 2016 at 3:25 PM, Cédric Champeau < > cedric.champ...@gmail.com> wrote: > >> A new release would be timely. Maybe we can try to get the 2.5 beta out >> too, would be nice for GR8Conf! >> >> What other fixes are in 2.4.7? >> >> 2016-05-20 14:34

Re: Automatic closure coercion and delegate

2016-05-02 18:11 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>: > On 02.05.2016 16:44, Cédric Champeau wrote: > [...] > >> Of course, it may look a bit superficial but it is super important for >> nice DSLs like in Gradle. >> > > could you give an example o

Automatic closure coercion and delegate

Hi guys, I've been grumpy about this for a bit too long to keep it for myself, so let me explain the issue :) Imagine you have a Java method that accepts a SAM type: interface Action { void execute(T object) } class Person { String name } void configure(Action config) {

Re: Release 2.5 Beta?

se it it's going to be hard to have >>>>> feedback. >>>> >>>> >>>> Agreed, it would be strange to not have any documentation for the focal >>>> point of a release. Are there any external references which we could direct >>>>

Re: Release 2.5 Beta?

nal references which we could direct >> users to? Not from within the repo itself, but when promoting the release >> elsewhere e.g. Twitter. >> >> On Sun, Mar 13, 2016 at 8:49 AM, Cédric Champeau < >> cedric.champ...@gmail.com> wrote: >> >>> So does everyo

Re: Release 2.5 Beta?

2016-03-12 0:05 GMT+01:00 Nicholas Grealy : > Looks like it's just you and me, Pascal! > > Just some questions for the broader dev community: > >- Who can perform the release? - Cédric looked like he single handedly >pushed out version 2.4.6 - can we ask him to

Re: [GitHub] groovy pull request: Link to MrHaki's blog in TupleConstructor jav...

2016-02-29 18:37 GMT+01:00 Konstantin Boudnik : > Sorry for a delay in the answer... > > On Mon, Feb 29, 2016 at 12:01PM, Jochen Theodorou wrote: > > > > On 27.02.2016 05:26, Aseem Bansal wrote: > > >Hi Konstantin Boudnik > > > > > >Are the things on groovy-lang not considered

Re: [GitHub] groovy pull request: Link to MrHaki's blog in TupleConstructor jav...

I don't think linking to external resources like this is a good idea. We don't own the end link, it can be dead very easily, especially in the future. I would rather improve the documentation. 2016-02-24 17:25 GMT+01:00 pledbrook : > GitHub user pledbrook opened a pull

Re: a new joint compiler

Hi Jochen, I need more context too. What changes are you talking about? It seems very abstract so far. I would be in favor of a joint compiler without stubs in Groovy core itself. I think both Gradle and Jetbrains would be interested in such a compiler too. And not talking about an incremental

[VOTE] Release Apache Groovy 2.4.6

Dear community, I am happy to start the VOTE thread for a Groovy 2.4.6! This release includes a lot of bugfixes since the last release, and is the first one since we went TLP. The changelog for this release can be found here:

Re: Preparing for a release

For Groovy Eclipse we have no choice: the Eclipse compiler is a fork of the Groovy compiler with Eclipse specific code. That's just how it works: new Groovy version, new Groovy Eclipse version. 2016-02-16 22:56 GMT+01:00 chrylis : > > Keeping small backwards

Re: Where is Groovy's roadmap?

I honestly don't think it's a problem that the roadmap disappeared. I have never seen a single Groovy roadmap that was up-to-date or realistic. My personal thought it that the roadmap is what the users want. So it depends on the pull requests we get, as well as what users want us to implement. At

Re: Release 2.4.6 and 2.5.0-beta?

o available at <http://repo.groovy-lang.org/> > http://repo.groovy-lang.org/ > > Cheers, can't wait for 2.5.0! > > On Tue, Dec 22, 2015 at 12:13 AM Cédric Champeau < > cedric.champ...@gmail.com> wrote: > >> Hi Pascal, >> >> Yes, there are a few things

<    1   2   3