No, we won't activate PRs on ci.groovy-lang.org for security reasons. They
should have been disabled for a long time, but apparently the TC
configuration to avoid them being built was wrong...
2015-12-02 19:16 GMT+01:00 John Wagenleitner :
> Thanks, looks like it picked up those pending PR's.
>
>
Hi Graeme,
That's very cool, I will launch a vote on private@ and will let you know
the result (votes usually last 48 hours).
Cheers,
Cédric
2015-12-10 8:52 GMT+01:00 Graeme Rocher :
> Hi all,
>
> I would like to request to become a committer again. I anticipate
> contributing frequently to Gr
I think this one is fine to integrate in 2.4.6.
2015-12-10 22:17 GMT+01:00 John Wagenleitner :
> Then I should mention that the recent PR 203 "Support for Array and
> Iterable not just Collection in JsonBuilder" [1] submitted I merged only
> into master since it was an enhancement. Depending on
:
> Please could my pull requests be merged before 2.4.6?
>
> On 10 Dec 2015, at 19:29, Pascal Schumacher
> wrote:
>
> Thanks. :)
>
> Are there any news regarding this?
>
> Thanks,
> Pascal
>
> Am 28.11.2015 um 16:59 schrieb Cédric Champeau:
>
> +1.
relying
on GH clones, but I don't recall what was the plan on that. Baruch
suggested the idea, so he may remember :)
2015-12-22 8:20 GMT+01:00 Pascal Schumacher :
> Hi Cédric,
>
> any updates concerning the release?
>
> Thanks,
> Pascal
>
>
> Am 11.12.2015 um 12:51 sc
I honestly didn't have time to take a look at this, but one thing I had in
mind was "oh, more methods, Android users won't be happy" :))
2015-12-24 10:19 GMT+01:00 Peter Ledbrook :
> Hi,
>
> I'm thinking of closing the above issue as Won't Fix. I think there are
> too many inconsistencies around
lable 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 t
FYI, Marco Vermeulen is going to work on scripts that are aimed towards
simplifying release process. As it is hardly possible now, we're likely
going to abandon releasing from TeamCity, and rely on Gradle build scripts
instead. Stay tuned.
2016-01-05 16:43 GMT+01:00 jim northrop :
> 1. Have done
+1
2016-01-15 19:42 GMT+01:00 Pascal Schumacher :
> Hello everybody,
>
> I think should disable auto-assignment of jira issues. Dozen of issues are
> assigned to people who do not currently work on them. I believe this stops
> people from contributing, because they think somebody is already worki
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
b
This page *is* up-to-date. It's the list of contributors to the
documentation.
2016-01-21 14:55 GMT+01:00 Aseem Bansal :
> If it is out of date then probably should change
> https://github.com/apache/groovy/edit/master/src/spec/doc/contributors.adoc
> for the link at the bottom
>
> I am not sure
As a side note, I'd like to conclude the decision about what to do with
regards to backwards compatibility in "next major groovy version", in
particular the decision about how to organize modules for jigsaw. I will
dig into my archives and revive the discussion :-)
Le 30 janv. 2016 10:18, "Jochen T
>>> I'm repeating myself, but we really should release 2.4.6. In another
>>> month the last bugfix release will be half a year ago.
>>>
>>> We should also release 2.5-beta, it may lack flashy features (beside the
>>> macro-stuff), but 2.4 was release
ache.org/jira/browse/GROOVY-7705>), I
>> chose not to backport my changes because they seemed to be more of an
>> enhancement to the static compiler than a bugfix. However, as I said in
>> that thread, I wouldn't be opposed to backporting the changes if other
>>
Hi guys,
As promised, I will try to find some time to perform a release this week.
The last one is months ago already, and even if we had decided to migrate
to a smoother process, nobody managed to made the modifications yet.
As such and if nobody disagrees, I will perform a release this week usi
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 compatible enhancements out of bugfix
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:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318
Is this JDK9 or JDK9 Jigsaw? Groovy is definitely broken on Jigsaw.
2016-02-22 9:25 GMT+01:00 Jochen Theodorou :
>
>
> On 21.02.2016 09:20, Russel Winder wrote:
>
>> Does it remain a "known thing" that the ASCIIDoctor tasks of the Groovy
>> build fail on JDK9?
>>
>
> What is the error you get?
>
Vote is now closed, here are the results:
10 "+1" votes (6 binding)
1 "0" vote
No negative vote.
I will proceed with the next steps, thanks!
2016-02-22 7:37 GMT+01:00 Paul King :
> +1
>
> On Sun, Feb 21, 2016 at 10:25 PM, Pascal Schumacher
> wrote:
> > Hi Konstantin,
> >
> > thanks for the in-
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 com
-1 on an upgrade that breaks rendering. JDK 9 support is broken and
deserves significant rewrites in any case.
2016-02-23 9:46 GMT+01:00 Russel Winder :
> On Mon, 2016-02-22 at 19:30 -0800, John Wagenleitner wrote:
> > Looks like the problem is fixed in asciidoctor-gradle-plugin:1.5.3
> > (master
It is a show stopper for groovy-core. We must *not* introduce a dependency
on Spock, because it would conflict with the version of Groovy that we are
using, and apply global xforms on Groovy core. While it might be ok, we
want to minimize the risks.
2016-02-24 12:35 GMT+01:00 Paul King :
> Spock
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 request:
>
> https://gi
ces, hidden away in some local m2 repo cache (or is that just me?).
> That’d make a stale link somewhat less likely, outweighed by the goodness
> of Groovy Goodness.
>
> -Jesper
>
> On 26. feb. 2016, at 08.35, Peter Ledbrook wrote:
>
> On Wed, 24 Feb 2016 at 16:30 Cédric Champ
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 originating from Apa
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 prepare the 2.5 beta release
it's going to be hard to
have feedback.
2016-03-13 0:56 GMT+01:00 Suderman Keith :
>
> On Mar 12, 2016, at 12:17 PM, Guillaume Laforge
> wrote:
>
> Let's go with mushroom, for a change :-)
>
>
> +1
>
>
> On Sat, Mar 12, 2016 at 5:32 PM, Cédric Champeau
uld 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 everyone agree that we s
Of course there are tests, but it's unlikely people will test a feature if
they have to look at unit tests to understand what it does.
2016-03-13 18:18 GMT+01:00 Guillaume Laforge :
> Aren't there any unit tests to point people to?
>
> On Sun, Mar 13, 2016 at 6:17
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) {
config.execut
2016-05-02 18:11 GMT+02:00 Jochen Theodorou :
> 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 of a more complex closure
is
often the one used in DSL, I could also see benefit in using delegate only
in the context of statically generated code...
2016-05-04 7:46 GMT+02:00 Mario Garcia :
> +1
>
> 2016-05-03 10:29 GMT+02:00 Jochen Theodorou :
>
>> On 03.05.2016 08:26, Cédric Champeau 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 GMT+02:00 Guillaume Laforge :
> I've just updated the issue.
>
> On Fri, May 20, 2016 at 2:23 PM, Daniel Spilker
> wrote:
>
>> Hi Guillaume,
>>
That's enough for a release I would say :)
2016-05-20 16:25 GMT+02:00 Daniel Spilker :
> According to JIRA, these issues have been resolved:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20GROOVY%20AND%20fixVersion%20%3D%202.4.7
>
> On Fri, May 20, 2016 at 3:25 PM
kype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>
> From: Cédric Champeau
>
> Reply: dev@groovy.apache.org
>
> Date: May 20, 2016 at 16:28:13
> To: dev@groovy.apache.org
> Subject: Re: 2.4.7 Release?
>
> That's enough for a
I'll do it.
2016-05-21 6:43 GMT+02:00 Andrew Bayer :
> It'd be really great if we could get 2.4.7 out in the next week or so in
> order to make it into the first Jenkins 2.x LTS - do we have a release
> manager to shepherd it through?
>
> A.
>
> On Fri, May 20, 2
he 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
> wrote:
>
>> I'll do it.
>>
>> 2016-05-21 6:43 GMT+02:00 Andrew Bayer :
>>
>>> It'd be re
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&version=12334898
Tag:
https://git1-us-west.apache.org/r
Indeed, copy/paste error, as usual :D
2016-06-03 19:53 GMT+02:00 Konstantin Boudnik :
> We are no longer PPMC, so it is ok to say it as it is - PMC ;)
>
> We'll cast my vote later today.
> Cos
>
> On Fri, Jun 03, 2016 at 07:20PM, Cédric Champeau wrote:
> > Dear com
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
Hi everyone!
The Apache Groovy team is pleased to announce the release of Apache Groovy
2.4.7! Apache Groovy is a multi-facet programming language for the JVM.
More information can be found at http://groovy-lang.org
This release include numerous bugfixes and we'd like to thank our growing
contrib
>>
>> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
>> Mobile: +45 40 44 91 88, Skype: sbglasius
>> --- Press ESC once to quit - twice to save the changes.
>>
>> From: Cédric Champeau
>>
>> Reply: dev@groovy.apache.org
>>
>> Date: 7. jun
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 grails-core-3.1.8(*1212 pass / 121
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 fails :-(
>
> …
> :gro
2016-07-05 15:03 GMT+02:00 Remi Forax :
> Just a note,
> Java has exactly the same bug when loading a class (at least Java before
> 9), when a class is not found, the classloader throw a
> ClassNotFoundException which may be catched by another classloader down the
> stack.
>
> The JIT (c2) even tr
AFAIK Asciidoctor uses JRuby and the version of JRuby here is not Java 9
compatible. Not even sure if any version of JRuby is.
2016-07-07 13:17 GMT+02:00 Russel Winder :
> After 18 mins of tense and anxious waiting, I have an installation of
> Groovy using JDK9. Sponditious. :-)
>
> However:
>
>
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 added the following ex
I was thinking of this but didn't get to send an email yet. I basically
think we should make Groovy 2.5 JDK 7+ only, and Groovy 3 JDK 8+.
2016-07-07 13:00 GMT+02:00 Russel Winder :
> Is it still required to have 1.6 as a base JDK version for new Groovy
> releases?
>
> Isn't it time to say if yo
Gradle 3.0 will require JDK 7. Gradle 2.x can run on JDK 6. I'm not a big
fan of "backporting". To me it's easier to complete 2.5 with JDK 7 now,
then switch master to 3.0 and upgrade to JDK 8 there. One of the reasons I
would consider this decision touchy is that Gradle would then not be able
to m
2016-07-08 9:10 GMT+02:00 Jochen Theodorou :
>
>
> On 07.07.2016 17:25, Cédric Champeau wrote:
>
>> Gradle 3.0 will require JDK 7. Gradle 2.x can run on JDK 6. I'm not a
>> big fan of "backporting". To me it's easier to complete 2.5 with JDK 7
>>
So I have patched the build to add the correct compile options for `javac`
in case JDK 9 is detected [1]. As the commit message states, groovy-xml
compile gets past compileJava, which is great, but then gets blocked by
groovyc, which doesn't see the javax.xml classes. This seems like a pretty
serio
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 of
2016-07-15 17:10 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 16:20, Cédric Champeau wrote:
>
>> 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
It generates a build scan, so that you can share the results (exceptions,
environment, build log, ...) independently of where the build is done. See
scans.gradle.com
2016-07-15 17:17 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:12, Cédric Champeau wrote:
> [...]
>
>> I&#x
Are you running with the wrapper?
./gradlew ...
2016-07-15 17:18 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:17, Jochen Theodorou wrote:
>
>> On 15.07.2016 17:12, Cédric Champeau wrote:
>> [...]
>>
>>> I'm just doing this:
>>>
>>
Can you try removing the `-XX:MaxPermSize=384m` option from
`gradle.properties` before running (with the wrapper)?
I'm not sure why I don't need to do it...
2016-07-15 17:18 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:17, Jochen Theodorou wrote:
>
>> On 15.07.2016
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 :
> On 15.07.2016 17:34, Cédric Champeau wrote:
>
>> Can you try removing the `-XX:MaxPermSize=384m` option from
>> `gradle.
You can use different init scripts, but you wouldn't influence the gradle
opts variable.
2016-07-15 17:52 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:50, Cédric Champeau wrote:
>
>> Yeah, I found why it passed in my local build: my
>> ~/.gradle/gradle.properties f
Could it be related to your startup option? XaddExports:jdk.compiler/com.s
un.tools.javac.api=ALL-UNNAMED
2016-07-15 17:56 GMT+02:00 Jochen Theodorou :
> ./gradlew -Dscan clean test
>
> gives me btw this result https://scans.gradle.com/s/3szt742ieifo6
>
> > BUG! exception in phase 'class generati
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 that doesn’t make sense to m
+1 for releasing but I'm just too busy for the next 2 weeks.
BTW, you can help improving our release process by contributing to this
repo:
https://github.com/groovy/groovy-release/blob/master/gradle/phase1.gradle
2016-09-11 20:27 GMT+02:00 Guillaume Laforge :
> +1 too, but we need to clone Cédri
I just installed Jigsaw b136. Let me know if it helps.
2016-09-18 9:48 GMT+02:00 Jochen Theodorou :
> On 18.09.2016 06:59, John Wagenleitner wrote:
> [...]
>
>> Thanks Guillaume and Jochen. It's good to see green again. :-)
>>
>
> now only the JDK9 builds are failing. At least for one of them I
classloader is now something that loads modules, so it's
> not a subclass of URLClassLoader anymore.
>
> Rémi
>
> - Mail original -
> > De: "Jochen Theodorou"
> > À: dev@groovy.apache.org
> > Envoyé: Dimanche 18 Septembre 2016 12:31:56
>
Fixed. The CI build that explodes the documentation was still looking for
"groovy-docs.zip" instead of "apache-groovy-docs.zip".
2016-09-18 14:19 GMT+02:00 Guillaume Laforge :
> Hi,
>
> Any idea why the "latest" documentation online:
> http://docs.groovy-lang.org/docs/next/html/documentation/
>
java.base/java.lang.reflect.Method.invoke(Method.java:529)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:77)
Which is f* annoying.
2016-09-18 13:46 GMT+02:00 Cédric Champeau :
> This seems to be a new error, I've never seen it before with Gradle 3.0+.
> It says:
>
> [Gr
ug" going to be fixed? Is there any way to disable that
behavior?
2016-09-18 15:03 GMT+02:00 Remi Forax :
>
>
> ------
>
> *De: *"Cédric Champeau"
> *À: *dev@groovy.apache.org
> *Envoyé: *Dimanche 18 Septembre 2016 14:39:30
> *Ob
gion.
2016-09-18 21:14 GMT+02:00 Jochen Theodorou :
> On 18.09.2016 15:03, Remi Forax wrote:
>
>>
>>
>> --------
>>
>> *De: *"Cédric Champeau"
>> *À: *dev@groovy.apache.org
>
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
> im
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 14:38 +0200, Jochen Theodo
I'm seeing the same, and no better luck with an explicit error message. I
tried with --no-daemon which goes a bit further but I doubt you'll be able
to work around those easily.
2016-09-26 21:14 GMT+02:00 Jochen Theodorou :
> Hi all,
>
> maybe some people here with more gradle knowledge can help
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 GMT+02
Nice, thanks John. Did you have a chance to test it with Gradle?
2016-09-29 17:21 GMT+02:00 John Wagenleitner :
> On Wed, Sep 28, 2016 at 11:35 PM, Cédric Champeau <
> cedric.champ...@gmail.com> wrote:
>
>> Ah that's annoying. We had to do this to workaround memory lea
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 has to be installed in order to build
>>> Groovy
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.
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 h
Hi there,
I'm going to try to upgrade TeamCity today. Don't worry if you don't see
the server online, hopefully the process shouldn't take too long.
Cheers,
Done. TeamCity has been upgraded to 10.0.2. I also installed JDK 9 Jigsaw
b139.
2016-10-16 14:22 GMT+02:00 Cédric Champeau :
> Hi there,
>
> I'm going to try to upgrade TeamCity today. Don't worry if you don't see
> the server online, hopefully the process shouldn't take too long.
>
> Cheers,
>
>
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 said,
2016-10-19 10:51 GMT+02:00 Jochen Theodorou :
>
>
> 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.
>>
>
> I think i
If we could get a fix for https://issues.apache.org/jira/browse/GROOVY-7966,
it would help Gradle, because it prevents our caching from working without
a hack (basically sorting files, which has a performance cost).
2016-10-19 16:32 GMT+02:00 Jochen Theodorou :
> Hi,
>
> I´dd like to collect here
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 :
> On 19.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 :
> On 20.10.2016 09:28, Cédric Champeau wrote:
>
>> I don't think it's reasonable to put
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 Groovy is using is not effic
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 Theodorou
> wrote:
>
>> O
day before a very important release.
>
> Rémi
>
> ------
>
> *De: *"Cédric Champeau"
> *À: *dev@groovy.apache.org
> *Envoyé: *Vendredi 28 Octobre 2016 09:03:36
> *Objet: *Re: replacing jarjar by gradle shadow plugin
>
> Yes, the s
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 are eligible
> for custom oper
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.
>
>The implementation is
+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 reorganize the project
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 :
> Daniel,
>
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" a écrit :
>
>> I just tried to
yes
2016-11-17 10:47 GMT+01:00 Russel Winder :
> 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:
>
> ./gradlew -Dscan install inst
Interesting, I'm not sure it is related...
2016-11-17 10:52 GMT+01:00 Russel Winder :
> 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:jarAll
> [ant:echo] Brid
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 in this
> > case I actual
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 operators:
>
> 1) !&& a !&&
I would say +1 to ?= . There are a few cases where I would have used it.
Typically, configuring some defaults after the fact. I'm not saying this is
a good pattern in general, but it can come handy:
void finalize(Config config) {
config.with {
foo ?= 'foo'
bar ?= 'bar'
baz ?=
Same here, +1 to ?=
This wasn't explicitly stated, but I want to make it clear, regarding the
semantics of this operator. I guess it implies "Groovy truth", not "null
check" (and we could apply the same kind of optimizations as we have for ?:
in static compilation).
2016-11-23 16:20 GMT+01:00 Gra
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 bugging
> me. I thought I'
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 w
Is it just me or Remi is advising to use a com.sun class?
Le 11 déc. 2016 17:18, "Daniel Sun" a écrit :
> Hi Paul,
>
> The built-in httpserver of JDK suggested by Remi seems better for us,
> it is stable and does not require 3rd party library:
>
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/f
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 y
1 - 100 of 336 matches
Mail list logo
