You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@asert.com.au> on 2018/05/19 15:40:05 UTC
[VOTE] Release Apache Groovy 2.5.0-rc-3
Dear development community,
I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
This release includes 27 bug fixes/improvements as outlined in the
changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12343166
Tag:
https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_0_RC_3
Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
The artifacts to be voted on are located as follows (r27001).
Source release:
https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-3/sources
Convenience binaries:
https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-3/distribution
Release artifacts are signed with a key from the following file:
https://dist.apache.org/repos/dist/dev/groovy/KEYS
Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
Reminder on ASF release approval requirements for PMC members:
http://www.apache.org/legal/release-policy.html#release-approval
Hints on validating checksums/signatures (but replace md5sum with
sha256sum):
https://www.apache.org/info/verification.html
The vote is open for the next 72 hours and passes if a majority of at least
three +1 PMC votes are cast.
[ ] +1 Release Apache Groovy 2.5.0-rc-3
[ ] 0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
Here is my vote:
+1 (binding)
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Andres Almiray <aa...@gmail.com>.
+1
Sent from my primitive Tricorder
> On 20 May 2018, at 18:45, Russel Winder <ru...@winder.org.uk> wrote:
>
>
>> [ ] +1 Release Apache Groovy 2.5.0-rc-3
>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>>
>>
>
> +1
>
> --
> Russel.
> ==========================================
> Dr Russel Winder t: +44 20 7585 2200
> 41 Buckmaster Road m: +44 7770 465 077
> London SW11 1EN, UK w: www.russel.org.uk
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Russel Winder <ru...@winder.org.uk>.
> [ ] +1 Release Apache Groovy 2.5.0-rc-3
> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>
>
+1
--
Russel.
==========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
No bug in your example. X is picked up correctly normally but not for the
forward reference in Daniel's example.
So in Daniel's example the forward reference issue is one bug (now fixed).
As to whether there is another bug I haven't checked. I'd say quite
possibly.
On Mon, May 21, 2018 at 8:32 PM, Jochen Theodorou <bl...@gmx.org> wrote:
> On 21.05.2018 03:23, Paul King wrote:
>
>>
>> I suspect there is some stray "X" class on the test classpath which keeps
>> the early checks happy until later resolution. Thanks for the fix.
>>
>
>
> isn't that a bug? If I declare
>
> class T<X> { X x}
>
> then I expect the generics used for the x property, not the class X, even
> if there is such a class. I am pretty sure Java is doing that, but even if
> it did not I would do that
>
> bye Jochen
>
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 21.05.2018 03:23, Paul King wrote:
>
> I suspect there is some stray "X" class on the test classpath which
> keeps the early checks happy until later resolution. Thanks for the fix.
isn't that a bug? If I declare
class T<X> { X x}
then I expect the generics used for the x property, not the class X,
even if there is such a class. I am pretty sure Java is doing that, but
even if it did not I would do that
bye Jochen
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
It's a requirement to keep the vote open to account for subsequent -1 votes
(except in circumstances like an emergency security fix).
On Mon, May 21, 2018 at 2:59 PM, Remko Popma <re...@gmail.com> wrote:
>
>
> > On May 21, 2018, at 13:35, Daniel.Sun <su...@apache.org> wrote:
> >
> > My pleasure :-)
> >
> > P.S. You've collected more than three +1 from PMC members.
>
> Still probably good to keep the vote open for the announced 72 hours in
> case someone finds a showstopper.
>
> Remko
> >
> > Cheers,
> > Daniel.Sun
> >
> >
> >
> > --
> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Remko Popma <re...@gmail.com>.
> On May 21, 2018, at 13:35, Daniel.Sun <su...@apache.org> wrote:
>
> My pleasure :-)
>
> P.S. You've collected more than three +1 from PMC members.
Still probably good to keep the vote open for the announced 72 hours in case someone finds a showstopper.
Remko
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by "Daniel.Sun" <su...@apache.org>.
My pleasure :-)
P.S. You've collected more than three +1 from PMC members.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
I suspect there is some stray "X" class on the test classpath which keeps
the early checks happy until later resolution. Thanks for the fix.
Cheers, Paul.
On Mon, May 21, 2018 at 1:29 AM, Daniel.Sun <su...@apache.org> wrote:
> +1
>
> All tests pass on my machine. Here is my machine info:
> ```
> ------------------------------------------------------------
> Gradle 4.7
> ------------------------------------------------------------
>
> Build time: 2018-04-18 09:09:12 UTC
> Revision: b9a962bf70638332300e7f810689cb2febbd4a6c
>
> Groovy: 2.4.12
> Ant: Apache Ant(TM) version 1.9.9 compiled on February 2 2017
> JVM: 1.8.0_152 (Oracle Corporation 25.152-b16)
> OS: Windows 10 10.0 amd64
> ```
>
> As a side note, the following test passes, but when running it in groovy
> console, it failed...
> ```
> @groovy.transform.CompileStatic
> public class Foo<T extends List<X>, X extends Number> {
> X getFirstElement(T t) {
> X x = t.get(0)
> return x
> }
>
> static void main(String[] args) {
> def f = new Foo<ArrayList<Integer>, Integer>()
> def list = new ArrayList<Integer>()
> list.add(123)
> assert 123 == f.getFirstElement(list)
> }
> }
> ```
> (https://github.com/apache/groovy/blob/GROOVY_2_5_X/src/test/groovy/bugs/
> Groovy6171Bug.groovy#L58)
>
> workaround:
> ```
> @groovy.transform.CompileStatic
> public class Foo<X extends Number, T extends List<X>> {
> X getFirstElement(T t) {
> X x = t.get(0)
> return x
> }
>
> static void main(String[] args) {
> def f = new Foo<Integer, ArrayList<Integer>>()
> def list = new ArrayList<Integer>()
> list.add(123)
> assert 123 == f.getFirstElement(list)
> }
> }
> ```
>
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Guillaume Laforge <gl...@gmail.com>.
+1
Le dim. 20 mai 2018 à 18:30, Daniel.Sun <su...@apache.org> a écrit :
> "GROOVY-6167" should be finally fixed by
> 1) fix resolving [1] (pushed just now, will be included in 2.5.0 GA)
> 2) fix type inference [2]
>
> But it's really weird, I still don't know the reason why the test[3] always
> passes...
>
> P.S. The issue number should be 6167(not 6171), it is fixed by too
>
>
> Cheers,
> Daniel.Sun
> [1]
>
> https://github.com/apache/groovy/commit/29e68b7d99a1e41a73a5e33a5bb0d3b436d03b5f
> [2]
>
> https://github.com/apache/groovy/commit/48807d5b1ba094e2f0dc212b6c92b4b370fe8394
>
> [3]
>
> https://github.com/apache/groovy/blob/GROOVY_2_5_0_RC_3/src/test/groovy/bugs/Groovy6171Bug.groovy#L58-L71
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by "Daniel.Sun" <su...@apache.org>.
"GROOVY-6167" should be finally fixed by
1) fix resolving [1] (pushed just now, will be included in 2.5.0 GA)
2) fix type inference [2]
But it's really weird, I still don't know the reason why the test[3] always
passes...
P.S. The issue number should be 6167(not 6171), it is fixed by too
Cheers,
Daniel.Sun
[1]
https://github.com/apache/groovy/commit/29e68b7d99a1e41a73a5e33a5bb0d3b436d03b5f
[2]
https://github.com/apache/groovy/commit/48807d5b1ba094e2f0dc212b6c92b4b370fe8394
[3]
https://github.com/apache/groovy/blob/GROOVY_2_5_0_RC_3/src/test/groovy/bugs/Groovy6171Bug.groovy#L58-L71
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by "Daniel.Sun" <su...@apache.org>.
+1
All tests pass on my machine. Here is my machine info:
```
------------------------------------------------------------
Gradle 4.7
------------------------------------------------------------
Build time: 2018-04-18 09:09:12 UTC
Revision: b9a962bf70638332300e7f810689cb2febbd4a6c
Groovy: 2.4.12
Ant: Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM: 1.8.0_152 (Oracle Corporation 25.152-b16)
OS: Windows 10 10.0 amd64
```
As a side note, the following test passes, but when running it in groovy
console, it failed...
```
@groovy.transform.CompileStatic
public class Foo<T extends List<X>, X extends Number> {
X getFirstElement(T t) {
X x = t.get(0)
return x
}
static void main(String[] args) {
def f = new Foo<ArrayList<Integer>, Integer>()
def list = new ArrayList<Integer>()
list.add(123)
assert 123 == f.getFirstElement(list)
}
}
```
(https://github.com/apache/groovy/blob/GROOVY_2_5_X/src/test/groovy/bugs/Groovy6171Bug.groovy#L58)
workaround:
```
@groovy.transform.CompileStatic
public class Foo<X extends Number, T extends List<X>> {
X getFirstElement(T t) {
X x = t.get(0)
return x
}
static void main(String[] args) {
def f = new Foo<Integer, ArrayList<Integer>>()
def list = new ArrayList<Integer>()
list.add(123)
assert 123 == f.getFirstElement(list)
}
}
```
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
It is a standard error message whenever any module doesn't load. The same
thing would occur when you try to load groovy-nio module on JDK6 (nio is a
JDK7+ feature) or if you had your own custom extension module which
referenced a third-party library and you didn't have that library in the
classpath or you had some security manager in place which prohibited that
functionality.
We could advertise the purpose of our modules a bit more and at least have
a one line README in each subproject and/or package.html/package-info.class.
On Tue, May 22, 2018 at 4:02 PM, Remko Popma <re...@gmail.com> wrote:
> Thanks for the clarification.
> It wasn’t clear to me that this was about the java.time package. Is it
> possible to improve the error message?
>
> Interesting about the preferences error. Was there a bug filed with
> Oracle? If I have time I can try to look into this further. Strange that I
> didn’t see this on Java 8 though...
>
> Remko
>
> On May 22, 2018, at 11:52, Paul King <pa...@asert.com.au> wrote:
>
>
> Sorry, I accidentally went off-list.
>
> ---------- Forwarded message ----------
> From: Paul King <pa...@asert.com.au>
> Date: Tue, May 22, 2018 at 12:22 PM
> Subject: Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
> To: Remko Popma <re...@gmail.com>
>
>
> The warnings are by design. The java.time classes are only in JDK8, so our
> extensions wouldn't make sense to load in JDK7.
>
> The windows warning is I guess a bug that we've never addressed. If you go
> into windows registry via regedit
> and create the "Prefs" directory manually, the error will go away on that
> machine. I believe we are just using
> Java classes to write out preferences and the assumption was that it was a
> Java bug that would eventually be fixed.
> Perhaps it's worth re-looking at. The consequence is that it won't
> remember if you change the groovyConsole window
> size or default font size etc. but everything else will still work as
> expected.
>
>
>
> On Tue, May 22, 2018 at 8:58 AM, Remko Popma <re...@gmail.com>
> wrote:
>
>> Potential Java 7 issue:
>>
>> When I run the grape, groovyDoc, groovyConsole or groovysh command line
>> tools with environment variable JAVA_HOME set to my JDK-7 installation, I
>> see two warnings that the extensions and the static extensions for Date
>> could not be installed.
>>
>> $ groovyDoc
>> May 22, 2018 7:52:28 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule
>> newModule
>> WARNING: Module [groovy-datetime] - Unable to load extension class
>> [org.apache.groovy.datetime.extensions.DateTimeExtensions]
>> May 22, 2018 7:52:28 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule
>> newModule
>> WARNING: Module [groovy-datetime] - Unable to load extension class
>> [org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
>>
>> With groovyConsole I additionally see a warning about preferences:
>>
>> $ groovyConsole -h
>> May 22, 2018 7:55:58 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule
>> newModule
>> WARNING: Module [groovy-datetime] - Unable to load extension class
>> [org.apache.groovy.datetime.extensions.DateTimeExtensions]
>> May 22, 2018 7:55:58 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule
>> newModule
>> WARNING: Module [groovy-datetime] - Unable to load extension class
>> [org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
>> May 22, 2018 7:55:58 AM java.util.prefs.WindowsPreferences <init>
>> WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at
>> root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
>>
>> Is anyone else also seeing this?
>>
>> Remko
>>
>> On Tue, May 22, 2018 at 0:27 Paul King <pa...@asert.com.au> wrote:
>>
>>> If you run: ./gradlew rat
>>> It should exclude all the necessary files using the excludes in
>>> gradle/quality.gradle
>>> (the excludes list actually has some extra entries so you can run it on
>>> the full repo - which includes a few things we don't put in the src zip)
>>>
>>> As for the other tools still using commons CLI, it was intentional
>>> originally as a way to test the legacy CliBuilder support but I think
>>> we have that in hand now, so PRs welcome.
>>>
>>> I fixed the getParser typo. Thanks for spotting that. It would have
>>> still worked but not achieved the desired outcome.
>>>
>>> We'll have to check all of the doco. There are numerous adoc files for
>>> tools-groovy, tools-groovyc, groovydoc, etc.
>>>
>>> Cheers, Paul.
>>>
>>>
>>> On Tue, May 22, 2018 at 12:04 AM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> When building the GROOVY_2_5_X branch, I see failing RAT tests:
>>>>
>>>> $project/subprojects/groovy-templates/out/test/resources/inc
>>>> ludes/hello-escaped.txt
>>>> $project/subprojects/groovy-templates/out/test/resources/inc
>>>> ludes/hello.html
>>>> $project/subprojects/groovy-templates/out/test/resources/raw.txt
>>>> $project/subprojects/groovy-templates/out/test/resources/to_
>>>> be_escaped.txt
>>>>
>>>> Not a showstopper, but can these be excluded from the RAT checks
>>>> somehow?
>>>>
>>>>
>>>> Other things I noticed (none of them showstoppers, I believe):
>>>>
>>>> Out of the command line tools in bin, three were migrated from
>>>> commons-cli to picocli (groovy, groovyc and grape), so they show usage help
>>>> in ANSI colors and have consistent version, help and classpath switches.
>>>> The others (groovysh, groovyConsole and groovydoc) either explicitly
>>>> import groovy.cli.commons.CliBuilder or implicitly import
>>>> groovy.util.CliBuilder. This means that these tools don't show help in ANSI
>>>> colors. Their version, help and classpath switches also look different than
>>>> the first-mentioned tools. If this was intentional then no problem.
>>>> Otherwise it may be good to import groovy.cli.picocli.CliBuilder so they
>>>> all have usage help in ANSI colors, and perhaps align the switches. If
>>>> there is interest I would like to generate auto-completion scripts for all
>>>> tools, if they are all picocli-based that becomes easier.
>>>>
>>>> groovy.util.CliBuilder now has two deprecated setParser methods. I
>>>> believe the intention is that the one on line 60 should be named getParser
>>>> instead?
>>>> Also, should a deprecated getter/setter for Options be added?
>>>>
>>>> The docs for the grape command line tool (groovy-2.5.0-rc-3/html/docume
>>>> ntation/grape.html#Grape-CommandLineTool) is a bit out of date:
>>>> missing the uninstall subcommand and missing the classifier argument for
>>>> the install subcommand.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, May 21, 2018 at 4:03 AM, Jochen Theodorou <bl...@gmx.org>
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> On 19.05.2018 17:40, Paul King wrote:
>>>>>
>>>>>>
>>>>>> Dear development community,
>>>>>>
>>>>>> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
>>>>>>
>>>>>> This release includes 27 bug fixes/improvements as outlined in the
>>>>>> changelog:
>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>>>>> ctId=12318123&version=12343166
>>>>>>
>>>>>> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag
>>>>>> ;h=refs/tags/GROOVY_2_5_0_RC_3
>>>>>> Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
>>>>>>
>>>>>> The artifacts to be voted on are located as follows (r27001).
>>>>>> Source release: https://dist.apache.org/repos/
>>>>>> dist/dev/groovy/2.5.0-rc-3/sources
>>>>>> Convenience binaries: https://dist.apache.org/repos/
>>>>>> dist/dev/groovy/2.5.0-rc-3/distribution
>>>>>>
>>>>>> Release artifacts are signed with a key from the following file:
>>>>>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>>>>>
>>>>>> Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
>>>>>>
>>>>>> Reminder on ASF release approval requirements for PMC members:
>>>>>> http://www.apache.org/legal/release-policy.html#release-approval
>>>>>> Hints on validating checksums/signatures (but replace md5sum with
>>>>>> sha256sum):
>>>>>> https://www.apache.org/info/verification.html
>>>>>>
>>>>>> The vote is open for the next 72 hours and passes if a majority of at
>>>>>> least three +1 PMC votes are cast.
>>>>>>
>>>>>> [ ] +1 Release Apache Groovy 2.5.0-rc-3
>>>>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>>>>>> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>>>>>>
>>>>>> Here is my vote:
>>>>>>
>>>>>> +1 (binding)
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Remko Popma <re...@gmail.com>.
Thanks for the clarification.
It wasn’t clear to me that this was about the java.time package. Is it possible to improve the error message?
Interesting about the preferences error. Was there a bug filed with Oracle? If I have time I can try to look into this further. Strange that I didn’t see this on Java 8 though...
Remko
> On May 22, 2018, at 11:52, Paul King <pa...@asert.com.au> wrote:
>
>
> Sorry, I accidentally went off-list.
>
> ---------- Forwarded message ----------
> From: Paul King <pa...@asert.com.au>
> Date: Tue, May 22, 2018 at 12:22 PM
> Subject: Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
> To: Remko Popma <re...@gmail.com>
>
>
> The warnings are by design. The java.time classes are only in JDK8, so our extensions wouldn't make sense to load in JDK7.
>
> The windows warning is I guess a bug that we've never addressed. If you go into windows registry via regedit
> and create the "Prefs" directory manually, the error will go away on that machine. I believe we are just using
> Java classes to write out preferences and the assumption was that it was a Java bug that would eventually be fixed.
> Perhaps it's worth re-looking at. The consequence is that it won't remember if you change the groovyConsole window
> size or default font size etc. but everything else will still work as expected.
>
>
>
>> On Tue, May 22, 2018 at 8:58 AM, Remko Popma <re...@gmail.com> wrote:
>> Potential Java 7 issue:
>>
>> When I run the grape, groovyDoc, groovyConsole or groovysh command line tools with environment variable JAVA_HOME set to my JDK-7 installation, I see two warnings that the extensions and the static extensions for Date could not be installed.
>>
>> $ groovyDoc
>> May 22, 2018 7:52:28 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
>> WARNING: Module [groovy-datetime] - Unable to load extension class [org.apache.groovy.datetime.extensions.DateTimeExtensions]
>> May 22, 2018 7:52:28 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
>> WARNING: Module [groovy-datetime] - Unable to load extension class [org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
>>
>> With groovyConsole I additionally see a warning about preferences:
>>
>> $ groovyConsole -h
>> May 22, 2018 7:55:58 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
>> WARNING: Module [groovy-datetime] - Unable to load extension class [org.apache.groovy.datetime.extensions.DateTimeExtensions]
>> May 22, 2018 7:55:58 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
>> WARNING: Module [groovy-datetime] - Unable to load extension class [org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
>> May 22, 2018 7:55:58 AM java.util.prefs.WindowsPreferences <init>
>> WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
>>
>> Is anyone else also seeing this?
>>
>> Remko
>>
>>> On Tue, May 22, 2018 at 0:27 Paul King <pa...@asert.com.au> wrote:
>>> If you run: ./gradlew rat
>>> It should exclude all the necessary files using the excludes in gradle/quality.gradle
>>> (the excludes list actually has some extra entries so you can run it on the full repo - which includes a few things we don't put in the src zip)
>>>
>>> As for the other tools still using commons CLI, it was intentional originally as a way to test the legacy CliBuilder support but I think
>>> we have that in hand now, so PRs welcome.
>>>
>>> I fixed the getParser typo. Thanks for spotting that. It would have still worked but not achieved the desired outcome.
>>>
>>> We'll have to check all of the doco. There are numerous adoc files for tools-groovy, tools-groovyc, groovydoc, etc.
>>>
>>> Cheers, Paul.
>>>
>>>
>>>> On Tue, May 22, 2018 at 12:04 AM, Remko Popma <re...@gmail.com> wrote:
>>>> +1
>>>>
>>>> When building the GROOVY_2_5_X branch, I see failing RAT tests:
>>>> $project/subprojects/groovy-templates/out/test/resources/includes/hello-escaped.txt
>>>> $project/subprojects/groovy-templates/out/test/resources/includes/hello.html
>>>> $project/subprojects/groovy-templates/out/test/resources/raw.txt
>>>> $project/subprojects/groovy-templates/out/test/resources/to_be_escaped.txt
>>>> Not a showstopper, but can these be excluded from the RAT checks somehow?
>>>>
>>>>
>>>> Other things I noticed (none of them showstoppers, I believe):
>>>>
>>>> Out of the command line tools in bin, three were migrated from commons-cli to picocli (groovy, groovyc and grape), so they show usage help in ANSI colors and have consistent version, help and classpath switches. The others (groovysh, groovyConsole and groovydoc) either explicitly import groovy.cli.commons.CliBuilder or implicitly import groovy.util.CliBuilder. This means that these tools don't show help in ANSI colors. Their version, help and classpath switches also look different than the first-mentioned tools. If this was intentional then no problem. Otherwise it may be good to import groovy.cli.picocli.CliBuilder so they all have usage help in ANSI colors, and perhaps align the switches. If there is interest I would like to generate auto-completion scripts for all tools, if they are all picocli-based that becomes easier.
>>>>
>>>> groovy.util.CliBuilder now has two deprecated setParser methods. I believe the intention is that the one on line 60 should be named getParser instead?
>>>> Also, should a deprecated getter/setter for Options be added?
>>>>
>>>> The docs for the grape command line tool (groovy-2.5.0-rc-3/html/documentation/grape.html#Grape-CommandLineTool) is a bit out of date: missing the uninstall subcommand and missing the classifier argument for the install subcommand.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Mon, May 21, 2018 at 4:03 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>>>>> +1
>>>>>
>>>>>> On 19.05.2018 17:40, Paul King wrote:
>>>>>>
>>>>>> Dear development community,
>>>>>>
>>>>>> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
>>>>>>
>>>>>> This release includes 27 bug fixes/improvements as outlined in the changelog:
>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12343166
>>>>>>
>>>>>> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_0_RC_3
>>>>>> Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
>>>>>>
>>>>>> The artifacts to be voted on are located as follows (r27001).
>>>>>> Source release: https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-3/sources
>>>>>> Convenience binaries: https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-3/distribution
>>>>>>
>>>>>> Release artifacts are signed with a key from the following file:
>>>>>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>>>>>
>>>>>> Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
>>>>>>
>>>>>> Reminder on ASF release approval requirements for PMC members:
>>>>>> http://www.apache.org/legal/release-policy.html#release-approval
>>>>>> Hints on validating checksums/signatures (but replace md5sum with sha256sum):
>>>>>> https://www.apache.org/info/verification.html
>>>>>>
>>>>>> The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast.
>>>>>>
>>>>>> [ ] +1 Release Apache Groovy 2.5.0-rc-3
>>>>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>>>>>> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>>>>>>
>>>>>> Here is my vote:
>>>>>>
>>>>>> +1 (binding)
>>>>>>
>>>>>
>>>>
>>>
>
>
Fwd: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
Sorry, I accidentally went off-list.
---------- Forwarded message ----------
From: Paul King <pa...@asert.com.au>
Date: Tue, May 22, 2018 at 12:22 PM
Subject: Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
To: Remko Popma <re...@gmail.com>
The warnings are by design. The java.time classes are only in JDK8, so our
extensions wouldn't make sense to load in JDK7.
The windows warning is I guess a bug that we've never addressed. If you go
into windows registry via regedit
and create the "Prefs" directory manually, the error will go away on that
machine. I believe we are just using
Java classes to write out preferences and the assumption was that it was a
Java bug that would eventually be fixed.
Perhaps it's worth re-looking at. The consequence is that it won't remember
if you change the groovyConsole window
size or default font size etc. but everything else will still work as
expected.
On Tue, May 22, 2018 at 8:58 AM, Remko Popma <re...@gmail.com> wrote:
> Potential Java 7 issue:
>
> When I run the grape, groovyDoc, groovyConsole or groovysh command line
> tools with environment variable JAVA_HOME set to my JDK-7 installation, I
> see two warnings that the extensions and the static extensions for Date
> could not be installed.
>
> $ groovyDoc
> May 22, 2018 7:52:28 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule
> newModule
> WARNING: Module [groovy-datetime] - Unable to load extension class
> [org.apache.groovy.datetime.extensions.DateTimeExtensions]
> May 22, 2018 7:52:28 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule
> newModule
> WARNING: Module [groovy-datetime] - Unable to load extension class
> [org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
>
> With groovyConsole I additionally see a warning about preferences:
>
> $ groovyConsole -h
> May 22, 2018 7:55:58 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule
> newModule
> WARNING: Module [groovy-datetime] - Unable to load extension class
> [org.apache.groovy.datetime.extensions.DateTimeExtensions]
> May 22, 2018 7:55:58 AM org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule
> newModule
> WARNING: Module [groovy-datetime] - Unable to load extension class
> [org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
> May 22, 2018 7:55:58 AM java.util.prefs.WindowsPreferences <init>
> WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at
> root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
>
> Is anyone else also seeing this?
>
> Remko
>
> On Tue, May 22, 2018 at 0:27 Paul King <pa...@asert.com.au> wrote:
>
>> If you run: ./gradlew rat
>> It should exclude all the necessary files using the excludes in
>> gradle/quality.gradle
>> (the excludes list actually has some extra entries so you can run it on
>> the full repo - which includes a few things we don't put in the src zip)
>>
>> As for the other tools still using commons CLI, it was intentional
>> originally as a way to test the legacy CliBuilder support but I think
>> we have that in hand now, so PRs welcome.
>>
>> I fixed the getParser typo. Thanks for spotting that. It would have still
>> worked but not achieved the desired outcome.
>>
>> We'll have to check all of the doco. There are numerous adoc files for
>> tools-groovy, tools-groovyc, groovydoc, etc.
>>
>> Cheers, Paul.
>>
>>
>> On Tue, May 22, 2018 at 12:04 AM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> +1
>>>
>>> When building the GROOVY_2_5_X branch, I see failing RAT tests:
>>>
>>> $project/subprojects/groovy-templates/out/test/resources/inc
>>> ludes/hello-escaped.txt
>>> $project/subprojects/groovy-templates/out/test/resources/inc
>>> ludes/hello.html
>>> $project/subprojects/groovy-templates/out/test/resources/raw.txt
>>> $project/subprojects/groovy-templates/out/test/resources/to_
>>> be_escaped.txt
>>>
>>> Not a showstopper, but can these be excluded from the RAT checks somehow?
>>>
>>>
>>> Other things I noticed (none of them showstoppers, I believe):
>>>
>>> Out of the command line tools in bin, three were migrated from
>>> commons-cli to picocli (groovy, groovyc and grape), so they show usage help
>>> in ANSI colors and have consistent version, help and classpath switches.
>>> The others (groovysh, groovyConsole and groovydoc) either explicitly
>>> import groovy.cli.commons.CliBuilder or implicitly import
>>> groovy.util.CliBuilder. This means that these tools don't show help in ANSI
>>> colors. Their version, help and classpath switches also look different than
>>> the first-mentioned tools. If this was intentional then no problem.
>>> Otherwise it may be good to import groovy.cli.picocli.CliBuilder so they
>>> all have usage help in ANSI colors, and perhaps align the switches. If
>>> there is interest I would like to generate auto-completion scripts for all
>>> tools, if they are all picocli-based that becomes easier.
>>>
>>> groovy.util.CliBuilder now has two deprecated setParser methods. I
>>> believe the intention is that the one on line 60 should be named getParser
>>> instead?
>>> Also, should a deprecated getter/setter for Options be added?
>>>
>>> The docs for the grape command line tool (groovy-2.5.0-rc-3/html/docume
>>> ntation/grape.html#Grape-CommandLineTool) is a bit out of date: missing
>>> the uninstall subcommand and missing the classifier argument for the
>>> install subcommand.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, May 21, 2018 at 4:03 AM, Jochen Theodorou <bl...@gmx.org>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> On 19.05.2018 17:40, Paul King wrote:
>>>>
>>>>>
>>>>> Dear development community,
>>>>>
>>>>> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
>>>>>
>>>>> This release includes 27 bug fixes/improvements as outlined in the
>>>>> changelog:
>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>>>> ctId=12318123&version=12343166
>>>>>
>>>>> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag
>>>>> ;h=refs/tags/GROOVY_2_5_0_RC_3
>>>>> Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
>>>>>
>>>>> The artifacts to be voted on are located as follows (r27001).
>>>>> Source release: https://dist.apache.org/repos/
>>>>> dist/dev/groovy/2.5.0-rc-3/sources
>>>>> Convenience binaries: https://dist.apache.org/repos/
>>>>> dist/dev/groovy/2.5.0-rc-3/distribution
>>>>>
>>>>> Release artifacts are signed with a key from the following file:
>>>>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>>>>
>>>>> Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
>>>>>
>>>>> Reminder on ASF release approval requirements for PMC members:
>>>>> http://www.apache.org/legal/release-policy.html#release-approval
>>>>> Hints on validating checksums/signatures (but replace md5sum with
>>>>> sha256sum):
>>>>> https://www.apache.org/info/verification.html
>>>>>
>>>>> The vote is open for the next 72 hours and passes if a majority of at
>>>>> least three +1 PMC votes are cast.
>>>>>
>>>>> [ ] +1 Release Apache Groovy 2.5.0-rc-3
>>>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>>>>> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>>>>>
>>>>> Here is my vote:
>>>>>
>>>>> +1 (binding)
>>>>>
>>>>>
>>>>
>>>
>>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Remko Popma <re...@gmail.com>.
Potential Java 7 issue:
When I run the grape, groovyDoc, groovyConsole or groovysh command line
tools with environment variable JAVA_HOME set to my JDK-7 installation, I
see two warnings that the extensions and the static extensions for Date
could not be installed.
$ groovyDoc
May 22, 2018 7:52:28 AM
org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-datetime] - Unable to load extension class
[org.apache.groovy.datetime.extensions.DateTimeExtensions]
May 22, 2018 7:52:28 AM
org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-datetime] - Unable to load extension class
[org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
With groovyConsole I additionally see a warning about preferences:
$ groovyConsole -h
May 22, 2018 7:55:58 AM
org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-datetime] - Unable to load extension class
[org.apache.groovy.datetime.extensions.DateTimeExtensions]
May 22, 2018 7:55:58 AM
org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-datetime] - Unable to load extension class
[org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
May 22, 2018 7:55:58 AM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at
root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
Is anyone else also seeing this?
Remko
On Tue, May 22, 2018 at 0:27 Paul King <pa...@asert.com.au> wrote:
> If you run: ./gradlew rat
> It should exclude all the necessary files using the excludes in
> gradle/quality.gradle
> (the excludes list actually has some extra entries so you can run it on
> the full repo - which includes a few things we don't put in the src zip)
>
> As for the other tools still using commons CLI, it was intentional
> originally as a way to test the legacy CliBuilder support but I think
> we have that in hand now, so PRs welcome.
>
> I fixed the getParser typo. Thanks for spotting that. It would have still
> worked but not achieved the desired outcome.
>
> We'll have to check all of the doco. There are numerous adoc files for
> tools-groovy, tools-groovyc, groovydoc, etc.
>
> Cheers, Paul.
>
>
> On Tue, May 22, 2018 at 12:04 AM, Remko Popma <re...@gmail.com>
> wrote:
>
>> +1
>>
>> When building the GROOVY_2_5_X branch, I see failing RAT tests:
>>
>> $project/subprojects/groovy-templates/out/test/resources/
>> includes/hello-escaped.txt
>> $project/subprojects/groovy-templates/out/test/resources/
>> includes/hello.html
>> $project/subprojects/groovy-templates/out/test/resources/raw.txt
>> $project/subprojects/groovy-templates/out/test/resources/
>> to_be_escaped.txt
>>
>> Not a showstopper, but can these be excluded from the RAT checks somehow?
>>
>>
>> Other things I noticed (none of them showstoppers, I believe):
>>
>> Out of the command line tools in bin, three were migrated from
>> commons-cli to picocli (groovy, groovyc and grape), so they show usage help
>> in ANSI colors and have consistent version, help and classpath switches.
>> The others (groovysh, groovyConsole and groovydoc) either explicitly
>> import groovy.cli.commons.CliBuilder or implicitly import
>> groovy.util.CliBuilder. This means that these tools don't show help in ANSI
>> colors. Their version, help and classpath switches also look different than
>> the first-mentioned tools. If this was intentional then no problem.
>> Otherwise it may be good to import groovy.cli.picocli.CliBuilder so they
>> all have usage help in ANSI colors, and perhaps align the switches. If
>> there is interest I would like to generate auto-completion scripts for all
>> tools, if they are all picocli-based that becomes easier.
>>
>> groovy.util.CliBuilder now has two deprecated setParser methods. I
>> believe the intention is that the one on line 60 should be named getParser
>> instead?
>> Also, should a deprecated getter/setter for Options be added?
>>
>> The docs for the grape command line tool (groovy-2.5.0-rc-3/html/
>> documentation/grape.html#Grape-CommandLineTool) is a bit out of date:
>> missing the uninstall subcommand and missing the classifier argument for
>> the install subcommand.
>>
>>
>>
>>
>>
>>
>> On Mon, May 21, 2018 at 4:03 AM, Jochen Theodorou <bl...@gmx.org>
>> wrote:
>>
>>> +1
>>>
>>> On 19.05.2018 17:40, Paul King wrote:
>>>
>>>>
>>>> Dear development community,
>>>>
>>>> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
>>>>
>>>> This release includes 27 bug fixes/improvements as outlined in the
>>>> changelog:
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>> projectId=12318123&version=12343166
>>>>
>>>> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=
>>>> tag;h=refs/tags/GROOVY_2_5_0_RC_3
>>>> Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
>>>>
>>>> The artifacts to be voted on are located as follows (r27001).
>>>> Source release: https://dist.apache.org/repos/
>>>> dist/dev/groovy/2.5.0-rc-3/sources
>>>> Convenience binaries: https://dist.apache.org/repos/
>>>> dist/dev/groovy/2.5.0-rc-3/distribution
>>>>
>>>> Release artifacts are signed with a key from the following file:
>>>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>>>
>>>> Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
>>>>
>>>> Reminder on ASF release approval requirements for PMC members:
>>>> http://www.apache.org/legal/release-policy.html#release-approval
>>>> Hints on validating checksums/signatures (but replace md5sum with
>>>> sha256sum):
>>>> https://www.apache.org/info/verification.html
>>>>
>>>> The vote is open for the next 72 hours and passes if a majority of at
>>>> least three +1 PMC votes are cast.
>>>>
>>>> [ ] +1 Release Apache Groovy 2.5.0-rc-3
>>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>>>> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>>>>
>>>> Here is my vote:
>>>>
>>>> +1 (binding)
>>>>
>>>>
>>>
>>
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Paul King <pa...@asert.com.au>.
If you run: ./gradlew rat
It should exclude all the necessary files using the excludes in
gradle/quality.gradle
(the excludes list actually has some extra entries so you can run it on the
full repo - which includes a few things we don't put in the src zip)
As for the other tools still using commons CLI, it was intentional
originally as a way to test the legacy CliBuilder support but I think
we have that in hand now, so PRs welcome.
I fixed the getParser typo. Thanks for spotting that. It would have still
worked but not achieved the desired outcome.
We'll have to check all of the doco. There are numerous adoc files for
tools-groovy, tools-groovyc, groovydoc, etc.
Cheers, Paul.
On Tue, May 22, 2018 at 12:04 AM, Remko Popma <re...@gmail.com> wrote:
> +1
>
> When building the GROOVY_2_5_X branch, I see failing RAT tests:
>
> $project/subprojects/groovy-templates/out/test/resources/inc
> ludes/hello-escaped.txt
> $project/subprojects/groovy-templates/out/test/resources/inc
> ludes/hello.html
> $project/subprojects/groovy-templates/out/test/resources/raw.txt
> $project/subprojects/groovy-templates/out/test/resources/to_be_escaped.txt
>
> Not a showstopper, but can these be excluded from the RAT checks somehow?
>
>
> Other things I noticed (none of them showstoppers, I believe):
>
> Out of the command line tools in bin, three were migrated from commons-cli
> to picocli (groovy, groovyc and grape), so they show usage help in ANSI
> colors and have consistent version, help and classpath switches. The others
> (groovysh, groovyConsole and groovydoc) either explicitly
> import groovy.cli.commons.CliBuilder or implicitly import
> groovy.util.CliBuilder. This means that these tools don't show help in ANSI
> colors. Their version, help and classpath switches also look different than
> the first-mentioned tools. If this was intentional then no problem.
> Otherwise it may be good to import groovy.cli.picocli.CliBuilder so they
> all have usage help in ANSI colors, and perhaps align the switches. If
> there is interest I would like to generate auto-completion scripts for all
> tools, if they are all picocli-based that becomes easier.
>
> groovy.util.CliBuilder now has two deprecated setParser methods. I believe
> the intention is that the one on line 60 should be named getParser instead?
> Also, should a deprecated getter/setter for Options be added?
>
> The docs for the grape command line tool (groovy-2.5.0-rc-3/html/
> documentation/grape.html#Grape-CommandLineTool) is a bit out of date:
> missing the uninstall subcommand and missing the classifier argument for
> the install subcommand.
>
>
>
>
>
>
> On Mon, May 21, 2018 at 4:03 AM, Jochen Theodorou <bl...@gmx.org>
> wrote:
>
>> +1
>>
>> On 19.05.2018 17:40, Paul King wrote:
>>
>>>
>>> Dear development community,
>>>
>>> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
>>>
>>> This release includes 27 bug fixes/improvements as outlined in the
>>> changelog:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>> ctId=12318123&version=12343166
>>>
>>> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag
>>> ;h=refs/tags/GROOVY_2_5_0_RC_3
>>> Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
>>>
>>> The artifacts to be voted on are located as follows (r27001).
>>> Source release: https://dist.apache.org/repos/
>>> dist/dev/groovy/2.5.0-rc-3/sources
>>> Convenience binaries: https://dist.apache.org/repos/
>>> dist/dev/groovy/2.5.0-rc-3/distribution
>>>
>>> Release artifacts are signed with a key from the following file:
>>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>>
>>> Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
>>>
>>> Reminder on ASF release approval requirements for PMC members:
>>> http://www.apache.org/legal/release-policy.html#release-approval
>>> Hints on validating checksums/signatures (but replace md5sum with
>>> sha256sum):
>>> https://www.apache.org/info/verification.html
>>>
>>> The vote is open for the next 72 hours and passes if a majority of at
>>> least three +1 PMC votes are cast.
>>>
>>> [ ] +1 Release Apache Groovy 2.5.0-rc-3
>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>>> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>>>
>>> Here is my vote:
>>>
>>> +1 (binding)
>>>
>>>
>>
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Remko Popma <re...@gmail.com>.
+1
When building the GROOVY_2_5_X branch, I see failing RAT tests:
$project/subprojects/groovy-templates/out/test/resources/inc
ludes/hello-escaped.txt
$project/subprojects/groovy-templates/out/test/resources/includes/hello.html
$project/subprojects/groovy-templates/out/test/resources/raw.txt
$project/subprojects/groovy-templates/out/test/resources/to_be_escaped.txt
Not a showstopper, but can these be excluded from the RAT checks somehow?
Other things I noticed (none of them showstoppers, I believe):
Out of the command line tools in bin, three were migrated from commons-cli
to picocli (groovy, groovyc and grape), so they show usage help in ANSI
colors and have consistent version, help and classpath switches. The others
(groovysh, groovyConsole and groovydoc) either explicitly
import groovy.cli.commons.CliBuilder or implicitly import
groovy.util.CliBuilder. This means that these tools don't show help in ANSI
colors. Their version, help and classpath switches also look different than
the first-mentioned tools. If this was intentional then no problem.
Otherwise it may be good to import groovy.cli.picocli.CliBuilder so they
all have usage help in ANSI colors, and perhaps align the switches. If
there is interest I would like to generate auto-completion scripts for all
tools, if they are all picocli-based that becomes easier.
groovy.util.CliBuilder now has two deprecated setParser methods. I believe
the intention is that the one on line 60 should be named getParser instead?
Also, should a deprecated getter/setter for Options be added?
The docs for the grape command line tool
(groovy-2.5.0-rc-3/html/documentation/grape.html#Grape-CommandLineTool) is
a bit out of date: missing the uninstall subcommand and missing the
classifier argument for the install subcommand.
On Mon, May 21, 2018 at 4:03 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> +1
>
> On 19.05.2018 17:40, Paul King wrote:
>
>>
>> Dear development community,
>>
>> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
>>
>> This release includes 27 bug fixes/improvements as outlined in the
>> changelog:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12318123&version=12343166
>>
>> Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag
>> ;h=refs/tags/GROOVY_2_5_0_RC_3
>> Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
>>
>> The artifacts to be voted on are located as follows (r27001).
>> Source release: https://dist.apache.org/repos/
>> dist/dev/groovy/2.5.0-rc-3/sources
>> Convenience binaries: https://dist.apache.org/repos/
>> dist/dev/groovy/2.5.0-rc-3/distribution
>>
>> Release artifacts are signed with a key from the following file:
>> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>>
>> Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
>>
>> Reminder on ASF release approval requirements for PMC members:
>> http://www.apache.org/legal/release-policy.html#release-approval
>> Hints on validating checksums/signatures (but replace md5sum with
>> sha256sum):
>> https://www.apache.org/info/verification.html
>>
>> The vote is open for the next 72 hours and passes if a majority of at
>> least three +1 PMC votes are cast.
>>
>> [ ] +1 Release Apache Groovy 2.5.0-rc-3
>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>>
>> Here is my vote:
>>
>> +1 (binding)
>>
>>
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by Jochen Theodorou <bl...@gmx.org>.
+1
On 19.05.2018 17:40, Paul King wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
>
> This release includes 27 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12343166
>
> Tag:
> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_0_RC_3
> Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
>
> The artifacts to be voted on are located as follows (r27001).
> Source release:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-3/sources
> Convenience binaries:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-3/distribution
>
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>
> Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
>
> Reminder on ASF release approval requirements for PMC members:
> http://www.apache.org/legal/release-policy.html#release-approval
> Hints on validating checksums/signatures (but replace md5sum with
> sha256sum):
> https://www.apache.org/info/verification.html
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 2.5.0-rc-3
> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>
> Here is my vote:
>
> +1 (binding)
>
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
Posted by John Wagenleitner <jo...@gmail.com>.
+1 (binding)
On Sat, May 19, 2018 at 8:40 AM Paul King <pa...@asert.com.au> wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.0-rc-3 release!
>
> This release includes 27 bug fixes/improvements as outlined in the
> changelog:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12343166
>
> Tag:
> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_0_RC_3
> Tag commit id: 6bff836d8373ff58f27f31106e9179eb4ab6b3ad
>
> The artifacts to be voted on are located as follows (r27001).
> Source release:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-3/sources
> Convenience binaries:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.0-rc-3/distribution
>
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>
> Please vote on releasing this package as Apache Groovy 2.5.0-rc-3.
>
> Reminder on ASF release approval requirements for PMC members:
> http://www.apache.org/legal/release-policy.html#release-approval
> Hints on validating checksums/signatures (but replace md5sum with
> sha256sum):
> https://www.apache.org/info/verification.html
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 2.5.0-rc-3
> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because...
>
> Here is my vote:
>
> +1 (binding)
>
>