Looks like CI server is not picking up pull requests from github, may be
related to changing the github project removing incubator.
John
> wrote:
>
>> I've reset the job to use the new URL - should pick up the PRs now, but
>> I'll see if I can get it to retrigger the existing ones...
>>
>> A.
>>
>> On Wed, Dec 2, 2015 at 12:31 PM, John Wagenleitner <
>> john.wagenleit...@g
;
>> Hello everybody,
>>
>> it would be very nice if somebody could grant John the missing JIRA
>> rights.
>>
>> Thanks,
>> Pascal
>>
>> Weitergeleitete Nachricht Betreff: [jira] [Commented]
>> (GROOVY-6634) Annotated enum
In looking at PR #210 "StreamingJsonBuilder - fix IllegalStateException
when writing unescaped output" [1] I noticed that commit c5c0cefb36 [2]
that introduced the unescaped output feature was merged into both master
and 2_4_X. I didn't think new features were normally introduced in patch
releases
se includes my commits) is out
> https://github.com/grails/grails-views/blob/master/json/src/main/groovy/grails/plugin/json/builder/StreamingJsonBuilder.java
>
> Cheers
> Graeme
>
> On 10 Dec 2015, at 21:58, John Wagenleitner
> wrote:
>
> In looking at PR #210 "S
Graeme's PR's have been merged. The asfgit bot and the Team City CI server
haven't picked them up yet, not sure if there's a problem or they are just
running behind.
On Fri, Dec 11, 2015 at 3:51 AM, Cédric Champeau
wrote:
> Yes I think it would be good to have Graeme's PRs merged into 2.4.6 bef
The builds.apache.org CI server doesn't seem to be picking up Github pull
requests. If there's a more appropriate way to report this kind of issue
please let me know and I'll follow it in the future.
Not sure but wonder if HandleMetaClass#myMetaClass was static to avoid
having to perform a lookup for each HMC instance. Probably not a issue but
thought I'd bring attention to it.
On Tue, Jan 5, 2016 at 10:13 AM, wrote:
> Repository: groovy
> Updated Branches:
> refs/heads/master 586a316da -
ds may work with different
> Metaclasses etc.)
>
> I do not know enough about this area of the code to judge if the lack of
> thread-safety is really a concern.
>
> I just merged the pull request because of Jochens +1 vote.
>
>
> Am 05.01.2016 um 20:31 schrieb John Wa
n and initializaton of anything that is visible across
> threads, so no external synchronization is required.
>
> what do you guys think?
>
> bye Jochen
>
> Am 06.01.2016 um 00:27 schrieb John Wagenleitner:
>
>> My mistake, I didn't know there was a PR associated t
A couple PR's I submitted where not picked up by builds.apache.org so I
opened an INFRA ticket 11057.
I agree, I think turning off auto-assignment would be a good idea.
+1
On Fri, Jan 15, 2016 at 10:42 AM, Pascal Schumacher <
pascalschumac...@gmx.net> wrote:
> Hello everybody,
>
> I think should disable auto-assignment of jira issues. Dozen of issues are
> assigned to people who do not currently
I think there is a problem with the PR since it's escaping the dollar sign
(left a comment). Other than that, if the extra slash were removed the
change looks ok to me.
On Fri, Jan 15, 2016 at 9:53 AM, Pascal Schumacher wrote:
> Hello everybody,
>
> is there anybody with unix shell scripting kn
The TC builds for JDK7 haven't run since Jan 15. Was looking to point
someone to the snapshots on jfrog and noticed they hadn't been updated in a
while.
John
I just ran into GROOVY-7742 [1] that affects both master and GROOVY_2_4_X
branches. I marked it as a blocker since it may have pretty widespread
impact, but I could be wrong so hope others will review. Ran into the
issue trying to use master to build Grails. There have been quite a number
of fix
Hi Jim,
I think the file you might be looking for is:
src/main/org/codehaus/groovy/runtime/StringGroovyMethods.java
On Tue, Feb 16, 2016 at 10:36 AM, Pascal Schumacher <
pascalschumac...@gmx.net> wrote:
> Hi Jim,
>
> not sure what you mean by "String.metadata function"?
>
> If you like to
7; request? The Jira he referred to is a small
>> backwards compatible enhancement (rather than bug fix). We'd normally
>> keep this for new releases but it does open up much nicer Spring
>> integration options, so I am not too worried about back-porting this
>> one.
+1
On Fri, Feb 19, 2016 at 2:26 AM, Jim Jagielski wrote:
> +1 (nonbinding)
> > On Feb 18, 2016, at 4:27 PM, Cédric Champeau
> wrote:
> >
> > 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,
Looks like the problem is fixed in asciidoctor-gradle-plugin:1.5.3 (master
currently using 1.5.2). I tested 1.5.3 and it works with the latest jdk9
snapshot release (ea+106), but it seems to add some odd headings in
tables. Haven't had time to look into it.
On Feb 22, 2016 4:12 AM, "Russel Winder
Yes that was my experience, the problems (added "Table of Contents" heading
in some cells) I was seeing in tables was not just with 1.5.3 and jdk9 but
also jdk7/8. That's why I didn't go ahead with bumping the version in
master.
On Tue, Feb 23, 2016 at 2:51 AM, Russel Winder wrote:
> On Tue, 20
This open issue looks like what I'm seeing. Though I haven't verified or
tried the suggested workaround:
https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/177
On Tuesday, February 23, 2016, Russel Winder wrote:
> On Tue, 2016-02-23 at 09:48 -0800, John Wagenleitner
The TeamCity JDK7 builds seem to be stuck for the last couple of days.
About to merge in PR 290 [1] and wanted to do a quick poll to see if there
were any objections since it touches quite a few files across core and
sub-modules. Any objections to merging this into master? And GROOVY_2_4_X?
[1] https://github.com/apache/groovy/pull/290
personally I tend to not use final for
local/parameters unless it's used in an anonymous inner class. Hopefully
the methods are short enough that the extra syntax is not needed to know if
it reassigned or not.
>
> 2016-04-24 21:46 GMT+02:00 Jochen Theodorou :
>
>> On 24.04.2016
Just catching up on this thread, very interesting discussion and will have
to give the posted test code a try.
You are right about the PhantomReference and it has been removed in master
[1] along with the local cache that used it. Due to some refactorings that
were not in 2_4_X at the time it was
collection. If so, from that I've seen that would still require some user
intervention (java.beans.Introspector.flushFromCaches(clazz)) in order to
clear the Introspector cache which keeps a Soft Reference to main method of
a Script class which in turns references the Class.
>
>
&g
On Mon, May 16, 2016 at 11:56 PM, Jochen Theodorou
wrote:
> On 17.05.2016 07:53, Alain Stalder wrote:
>
>> That looks very good to me :)
>>
>> I will definitely try out the InvokerHelper.removeClass(clazz) with
>> added ClassInfo removal plus Introspector.flushFromCaches(clazz) and see
>> if I ca
On Tue, May 17, 2016 at 12:48 AM, Alain Stalder wrote:
>
> On 17.05.16 09:04, Alain Stalder wrote:
>
> PS: Note that Introspector.flushFromCaches(clazz) was experimentally
> really not necessary in this case, but maybe has to do with the simple
> nature of the test script ("42") and only calling
On Tue, May 17, 2016 at 12:23 PM, Alain Stalder wrote:
> [...]
>
> As I said, so far rather a hack, probably better to reimplement the
> GroovyClassValuePreJava7 class instead? Performance under concurrent use?
> Are other caches that apparently exist in ClassInfo also no issue under
> different
+1
On Jun 3, 2016 10:20 AM, "Cédric Champeau" wrote:
> 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
Having the full stack trace of one blocked thread and the blocking thread
would help. Also, would be helpful to see how the template engine is used
in code if possible.
On Jun 20, 2016 7:48 PM, "lp_forum" wrote:
Hi,
I have a very simple single page app using Java 7 + Spring Boot 1.3.3 +
Groovy
Since the java.xml.bind module is no longer resolved by default (it's now
part of the java.se.ee group) it must be explicitly added to the list of
modules in order for the :groovy-xml:compileGroovy task to complete. In
order to get the latest jdk-9 snapshot build to run locally I added the
followi
On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder wrote:
> On Fri, 2016-07-08 at 14:34 +0100, Russel Winder wrote:
> > Turns out it is not a Groovy or Gradle thing, it seems the Java
> > executable doesn't like the options it advertises it responds to.
> >
> > > > (export _JAVA_OPTIONS="-addmods java
> `-release` option of javac we can avoid `addmods` and the 1.9 target level
> issue at the same time.
>
>
> [1]
> https://github.com/apache/groovy/commit/380ae614ae4d979f00e6e362d210e2dd1295bdce
>
> 2016-07-08 16:29 GMT+02:00 John Wagenleitner
> :
>
>>
>>
>
I think that's a good idea. Having a new package under the normal src
directory in master with some sort of feature toggle I think would be good
and would be easier for some to help test or contribute.
With this work and with jigsaw coming it would be nice to release a 2.5 and
get master on a pat
On Mon, Aug 8, 2016 at 7:34 AM, Jochen Theodorou wrote:
>
>
> On 07.08.2016 18:09, John Wagenleitner wrote:
>
>> I think that's a good idea. Having a new package under the normal src
>> directory in master with some sort of feature toggle I think would be
>> g
On Wed, Aug 24, 2016 at 2:32 PM, Jochen Theodorou wrote:
> Hi all,
>
> I made two more tests pass with JDK9 and we are now down to 8 failures in
> groovy-core.
>
> gls.innerClass.InnerClassTest > testThisReferenceForAICInOpenBlock FAILED
>> groovy.lang.MissingMethodException: No signature of
On Wed, Aug 24, 2016 at 10:29 PM, Jochen Theodorou
wrote:
> On 25.08.2016 01:14, John Wagenleitner wrote:
> [...]
>
>> groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
>> org.codehaus.groovy.control.Mu
>> <http
On Thu, Aug 25, 2016 at 7:57 AM, John Wagenleitner <
john.wagenleit...@gmail.com> wrote:
>
> On Wed, Aug 24, 2016 at 10:29 PM, Jochen Theodorou
> wrote:
>
>> On 25.08.2016 01:14, John Wagenleitner wrote:
>> [...]
>>
>>> groovy.transform.
On Sat, Aug 27, 2016 at 4:22 AM, Jochen Theodorou wrote:
> On 27.08.2016 12:22, Paul King wrote:
>
>> I am just wondering what people's thoughts are on the different
>> approaches different parts of Groovy take for method resolution when
>> multiple methods are matched.
>>
>> Given this code:
>>
On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou wrote:
>
>
> On 07.09.2016 14:33, Thibault Kruse wrote:
>
>> The groovysh tests failed last because the strategy to read package
>> contents via the ClassLoader does not work with Java8. Possibly
>> checking how the new Java REPL does things could
On Wed, Sep 7, 2016 at 11:55 AM, Jochen Theodorou wrote:
> On 07.09.2016 19:54, John Wagenleitner wrote:
>
>> On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou > <mailto:blackd...@gmx.org>> wrote:
>>
>>
>>
>> On 07.09.2016 14:33, Thibault Krus
The jdk7 and 8 builds are failing. One commit I pushed yesterday
(GROOVY-7683) timed out and since subsequent pushes are failing with the
message:
org.gradle.cache.internal.LockTimeoutException: Timeout waiting to lock
Plugin Resolution Cache
(/var/teamcity/.gradle/caches/3.0/plugin-resolution).
On Sat, Sep 17, 2016 at 9:12 AM, Guillaume Laforge
wrote:
> Hi there,
>
> Quick heads-up on continuous integration on TeamCity.
>
> The builds were stuck for a while because of some Gradle bug when Gradle
> is run in parallel and corrupts the cache, or when Gradle crashes not
> cleaning caches an
A recent commit [1] to ClassInfo changed a private field from a Class to a
WeakReference (to address memory leaks). In testing a project with
the latest snapshot as a dependency, the compileGroovy task fails [2]
because that field is referenced in an internal Gradle
class LeakyOnJava7GroovySystemL
-- Forwarded message --
From: Jochen Theodorou
Date: Mon, Sep 19, 2016 at 12:12 AM
Subject: Re: Recent commit breaks gradle builds
To: dev@groovy.apache.org
On 19.09.2016 01:49, John Wagenleitner wrote:
> A recent commit [1] to ClassInfo changed a private field from a Class
On Mon, Sep 26, 2016 at 12:14 PM, Jochen Theodorou
wrote:
> Hi all,
>
> maybe some people here with more gradle knowledge can help me a bit. I am
> trying to run the jigsaw-136 build, of which I know gradle has problems
> with, but well I am trying to work around those. So I am starting our build
It might be related to GROOVY-7683 [1]. I ran the script
with 2.4.8-SNAPSHOT and it completes successfully. I can replicate the
problem with 2.4.7. As a workaround, I can get it to work with 2.4.7 if I
use the following:
groovy -Dgroovy.use.classvalue=true groovyOOM.groovy
[1] https://issue
>
> 2016-09-19 1:49 GMT+02:00 John Wagenleitner :
>
>> A recent commit [1] to ClassInfo changed a private field from a Class to
>> a WeakReference (to address memory leaks). In testing a project
>> with the latest snapshot as a dependency, the compileGroovy task fail
not
sure if those are the right tasks that would have exercised the use of the
LeakyOnJava7GroovySystemLoader.
>
> 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:
>
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 master.
>>
>> Along with Groovies 2.0.8, 2.1.9, 2.2.2, 2.3.10, 2.3.11, and 2.4.4.
>>
>> Someone, somewhere is
On Tue, Sep 27, 2016 at 11:15 AM, John Wagenleitner <
john.wagenleit...@gmail.com> wrote:
> On Mon, Sep 26, 2016 at 12:14 PM, Jochen Theodorou
> wrote:
>
>> Hi all,
>>
>> maybe some people here with more gradle knowledge can help me a bit. I am
>> trying
On Sat, Oct 1, 2016 at 12:55 AM, Jochen Theodorou wrote:
> hi all,
>
> as you guys may remember we added
>
> private Object readResolve() {
>> if (ALLOW_RESOLVE) {
>> return this;
>> }
>> throw new UnsupportedOperationException();
>> }
>>
>
> to prevent proper deserialization of a Metho
On Sat, Oct 1, 2016 at 10:52 PM, Jochen Theodorou wrote:
> On 02.10.2016 07:50, Jochen Theodorou wrote:
>
>> On 02.10.2016 02:57, John Wagenleitner wrote:
>> [...]
>>
>
> ah yes, I forgot:
>
> private void readObject(java.io.ObjectInput
On Thu, Oct 6, 2016 at 3:46 AM, Russel Winder wrote:
>
> I recollect this is a "known problem", but have forgotten what the
> answer was. Do we know what we have to campaigh for to get whatever it
> is fixed so this isn't broken?
>
>
> :asciidoctorAssets
>
> FAILURE: Build failed with an exceptio
On Tue, Oct 25, 2016 at 1:53 PM, Jochen Theodorou wrote:
> Hi,
>
> I am looking a bit into the usage of our old parser and keeping in mind
> the new parser we want to eventually make the default.
>
> But one problem I talked about in the past already is the direct usage of
> antlr2 types in somet
On Thu, Oct 27, 2016 at 1:25 AM, Guillaume Laforge
wrote:
> Hi there,
>
> I just saw this article yesterday: "Parsing JSON is a mine filed"
> http://seriot.ch/parsing_json.html
>
> I haven't read it (yet) in details, but we might be able to improve
> Groovy's JSON parsing support by going through
Welcome Sergei!
On Sat, Dec 10, 2016 at 1:08 AM, Cédric Champeau
wrote:
> 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 ve
On Sun, Dec 18, 2016 at 6:42 AM, Russel Winder wrote:
> (And Guillaume this is on Debian Sid using OpenJDK8 from the packaging,
> but this is irrelevant to the problem… :-)
>
> BTW are all build recorded by Gradle Inc?
>
>
>
> |> ./gradlew clean
> :buildSrc:compileJava UP-TO-DATE
> :buildSrc:comp
When I run `gradlew install` from source (both from the downloaded zip and
from the GROOVY_2_4_8 tag) I get the error below. Looks like prior to
commit 9fa4b015e4a80ef03 [1] this was a warning but now it fails the build
and wont install the artifacts in the local maven repo.
[1]
https://github.co
Paul King wrote:
> Can you check the version of gradle that is running? The artifacts are
> built using install and install works fine for me from the src zip.
>
> On Tue, Jan 10, 2017 at 12:33 PM, John Wagenleitner
> wrote:
> > When I run `gradlew install` from source (bo
On Tue, Jan 17, 2017 at 1:55 AM, Daniel Sun wrote:
> Hi Andres,
>
> > I'd suggest to release 2.5.0-beta and 3.0-ea together. Just like the JDK
> > team has been posting JDK9 EA releases, we could do the same. We know for
> > a fact we're going to break things, so let's make sure the public has
>
+1
On Feb 24, 2017 1:49 AM, "Paul King" wrote:
Dear community,
I am happy to start the VOTE thread for a Groovy 2.4.9 release!
This release includes 12 bug fixes/improvements as outlined in the
changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12318123&version=123391
On Tue, Mar 7, 2017 at 1:40 PM, Paul King wrote:
> Hi,
>
> I am planning to merge PR#508 and start the release process for 2.4.10
> over the next few days. This contains an important bug fix that
> affects downstream projects such as Grails. Any other fixes people
> want in that release?
>
> Soon
+1
Just wanted to note that in testing I came across some method names in
tests that had characters that are now no longer allowed in method names
[1] [2]. I know this is related to the fix for GROOVY-6792, just thought
it was odd that it seems to have worked in some cases before.
[1]
https://gi
+1
On Tue, Mar 14, 2017 at 8:05 AM, Paul King wrote:
> Dear community,
>
> I am happy to (re)start the VOTE thread for a Groovy 2.4.10 release!
> This release has the problematic stricter method checking
> (GROOVY-6792) disabled by default but it can be enabled with a system
> property. Thanks J
+1
On Wed, Mar 29, 2017 at 10:49 PM, Paul King wrote:
> Dear community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-alpha-1 release!
>
> This release includes 165 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> pro
I remember looking at this and seeing that the commit that originally
introduced the check was 2f077109 [1]. Subsequent commits switched to
CachedClass and later back to Class for the argument type to that method
but things got out of sync between MethodIndexAction and the local MOPIter
class leav
I created https://issues.apache.org/jira/browse/GROOVY-8140 for this and
will remove the method.
On Sat, Apr 1, 2017 at 2:14 PM, Jochen Theodorou wrote:
> On 01.04.2017 20:04, John Wagenleitner wrote:
>
>> I remember looking at this and seeing that the commit that originally
>&
On Sat, Apr 8, 2017 at 1:11 AM, Jochen Theodorou wrote:
> Hi all,
>
> so if we want to be serious about JDK9 support and not life with a
> thousands of warnings displayed whenever you try to execute a Groovy
> program or test (44k+ in our build for example)... then we will need JDK9
> specific co
I think if you run the 'check' task with -Pcoverage it'll generate the
jacoco reports.
On Tue, Apr 11, 2017 at 9:27 AM, Daniel Sun wrote:
> Hi all,
>
> Where can I find the code coverage report of Groovy? If there is no
> such thing currently, how about supporting it by leveraging the powe
On Thu, Apr 20, 2017 at 9:11 AM, 孙 岚 wrote:
> Hi all,
>
> I noticed that the performance of master is better than GROOVY_2_5_X.
>
> About *17% time saved* when running tests in the TeamCity CI
> instance:
> *master costs 18m:55s(TeamCity CI, Parrot disabled)*
> http://ci.groovy-lang.o
Hi Daniel,
Thanks, I had missed that. How do the tests under
"subprojects/groovy-parser-antlr4/src/test" get run or are they not enabled
on purpose?
John
On Thu, Apr 20, 2017 at 4:07 PM, 孙 岚 wrote:
> Hi John,
>
> Parrot will be enabled for all projects:
> https://github.com/apache/groovy/blob
On Fri, Apr 21, 2017 at 3:17 AM, Harish Dewan
wrote:
> Hi All,
> To solve a probable problem, I forked and clone a git repo (
> https://github.com/apache/groovy.git ) for groovy and then used this
> tutorial blog to import project in Intelj Idea ide (
> http://melix.github.io/blog/2014/06/contrib
0 (binding)
I am finding that the fix [1] for GROOVY-8127 is causing a number of test
failures [2] on the Grails master branch mostly related to the
DirtyCheckable trait [3]. Same tests pass with 2.4.10. Lack of knowledge
in this area so thus the neutral vote instead of -1.
[1] https://github.c
g
> conservative I will re-cut the build.
>
> Cheers, Paul.
>
> On Wed, Apr 26, 2017 at 7:09 PM, Paul King wrote:
>
>> John, what steps are you using to test?
>>
>> On Wed, Apr 26, 2017 at 3:10 PM, John Wagenleitner <
>> john.wagenleit...@gmail.com&g
l do you think we can have a release by tomorrow? It seems to be
>>> hard given the 48h vote. Basically cancelling this vote forces us to
>>> release Gradle 4.0-milestone-1 with a snapshot version of Groovy (duh).
>>>
>>> 2017-04-26 17:08 GMT+02:00 John Wagenlei
I think that's a great idea. The Contribute page [1] on groovy-lang.org
currently links to the 'contrib' label for "..possible easy contributions
that could get you started on your journey to become a Groovy committer."
I used that link when I first started looking for ways to contribute. I
thin
Hi James,
My opinion is that it should fail to parse, similar to the following:
import groovy.json.*
def parser = new JsonSlurper().setType(JsonParserType.INDEX_OVERLAY)
parser.parseText('{"num": 6-}')
//groovy.json.JsonException: unexpected character -
//
//The current charac
Hi Emilian,
I added a comment on that issue, I think it would also be handy to have a
new Preferences dialog for general settings such as this. Having a dialog
behind a new menu item such as Edit > Preferences could have an edit box
for inputting/displaying the output limit that is backed by a pre
orks which I just used the other week for some small parser.
>
> Also, this console would also make a fine IDE plugin. Any particular
> reason GroovyConsole has to be standalone?
>
>
I know IDEA provides a GroovyConsole and GroovyShell under the Tools menu
when Groovy is part of the pro
nces menu
>
>
> --emi
>
> On Sat, May 20, 2017 at 6:16 PM, John Wagenleitner <
> john.wagenleit...@gmail.com> wrote:
>
>> Hi Emilian,
>>
>> On Sat, May 20, 2017 at 7:35 AM, Emilian Bold
>> wrote:
>>
>>> You initial dialog is a
Does indy by default mean
1. only generate one set of groovy-* artifacts where any .groovy source
files in the Groovy source itself are compiled using indy (no more separate
indy jars)
or
2. continue to have two sets of artifacts where the indy set would go in
lib/ by default and -noindy jars
+1 (binding)
On Fri, Jun 2, 2017 at 7:33 AM, Jochen Theodorou wrote:
> Dear community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-beta-1 release!
>
> This release includes 8 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote
I like the idea of using a MethodHandle and it seems like a nice solution
that wouldn't require building with Java 9. Though I imagine that there
will probably be other changes that may require using the new module
related classes that would require building with Java 9.
On Sun, Jun 4, 2017 at 10
+1 (binding)
On Wed, Jun 21, 2017 at 3:15 AM, Paul King wrote:
>
> Dear community,
>
> I am happy to start the VOTE thread for a Groovy 2.4.12 release!
>
> This release includes 16 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>
I changed the test to redirect the TestNG test-output directory and place
it under the target directory, so it should work to re-enable the rat task.
On Sun, Jul 2, 2017 at 10:16 PM, Yazad Khambata wrote:
> Hi,
>
> Thank you Paul for the note.
>
> I looked for the settings for a while in gradle
The 2.4 branch still supports Java 6+ and believe that 2.5+ is where Java 7
starts as a baseline. The VMPlugin mechanism may be one approach to
consider, having it provide a setAccessible(AccessibleObject) method where
the Java7 or higher plugins can invoke the MethodHandle if available or
fall ba
Looks like the InjectedInvoker [1] is an implementation detail of the MH
lookup, probably used to allow calling the caller sensitive method. I did
not think that trySetAccessible prevents the message from appearing, so
even using that new method wont get rid of the warning even with the
default of
+1
One thing I noticed that I don't think was mentioned so far is that the
documentation from the sdk (doc/html/api) and docs (html/api/) archives
looks to contain some Chinese text.
On Sat, Aug 19, 2017 at 11:15 PM, Daniel Sun
wrote:
> Dear community,
>
> I am happy to start the VOTE thread fo
I think rolling back to Gradle 3.5.1 for 2_6_X is a good idea.
On Mon, Aug 28, 2017 at 4:07 PM, Paul King wrote:
> I think one of the issues is that our build doesn't seem to play well with
> Gradle 4+. Should we roll back to Gradle 3.5.1 for now? What do people
> think?
>
> Cheers, Paul.
>
> On
+1 (binding)
On Sun, Oct 1, 2017 at 8:16 PM, Paul King wrote:
>
> Dear community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-beta-2 release!
>
> This release includes 22 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jsp
I would be in favor of removing Unsafe from the groovy-json subproject
which I think is the only place where it's used. I had planned to propose
this to the dev list but never got around to it. With compat strings in
Java 9 I believe it will no longer be a viable optimization (at least not
without
+1
On Nov 19, 2017 3:25 AM, "Paul King" wrote:
>
> Dear community,
>
> I am happy to start the VOTE thread for a Groovy 2.4.13 release! This
> version fixes the problems reported with the previous candidate.
>
> This release includes 45 bug fixes/improvements as outlined in the
> changelog:
> ht
+1 (binding)
On Feb 19, 2018 9:36 PM, "Paul King" wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-beta-3 release!
>
> There are still a few things we plan to work on before the final release
> but
> we anticipate this will be the last beta for th
+1 (binding)
On Sat, Feb 24, 2018 at 3:46 AM, Paul King wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.4.14 release!
>
> This release includes 14 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseN
+1 (binding)
On Fri, Mar 2, 2018 at 8:21 AM, Daniel.Sun wrote:
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.6.0-alpha-3 release!
>
> This release includes 18 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/Rel
+1 (binding)
On Fri, Mar 23, 2018, 12:04 AM Paul King wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.4.15 release! This is
> mainly to fix a regression in calling static methods in interfaces. We were
> trying to improve the JDK9 experience but on t
+1 (binding)
On Thu, Apr 5, 2018, 9:14 AM Paul King wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-1 release!
>
> This release includes 18 bug fixes/improvements as outlined in the
> changelog:
>
> https://issues.apache.org/jira/secure/Releas
+1 (binding)
On Fri, Apr 13, 2018 at 8:20 AM, Daniel.Sun wrote:
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 3.0.0-alpha-2 release!
>
> This release includes 40 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/Re
1 - 100 of 128 matches
Mail list logo
