Hi Jacopo,
thanks for the information. :)
The update to Commons CLI 1.3 is part of master (will be Groovy 2.5). We
should of course update this to 1.3.1.
Groovy 2.4.X will continue to use Commons CLI 1.2.
Kind regards,
Pascal
Am 15.06.2015 um 05:53 schrieb Jacopo Cappellato:
For your infor
>
> > I have a different take on this. I think intersect() is by definition a
> > set operation and the method on Iterable is simply a convenience that
> > automatically converts the object and the arguments to sets. I would
> > even argue for the result of the method always being a set as well.
>
Right, so returns false for JDK <9 and true for JDK >= 9. That's more than
confusing, and a bit of a problem. It is "funny" that the docs says
"returns empty string if it's an anonymous class", and that now it is "if
it returns empty string, then it's an anonymous class". The logic is pretty
revers
Am 14.06.2015 16:54, schrieb Cédric Champeau:
[...]
I don't feel it is as easy as fixing a test. First of all, our closure
generated classes are *not* anonymous. ClosureWriter doesn't generate
anonymous classes, and we can verify it easily:
def cl = { -> '' }
assert cl.class.anonymousClass == fa
For your information,
the Apache Commons community is in the process of releasing the bug fix release
1.3.1 of Commons CLI in order to fix "a pretty severe bug" that was introduced
with the recent 1.3:
https://issues.apache.org/jira/browse/CLI-252
Should we wait for the new release before proc
Hello everybody,
what about removing "/security" and "src/test/groovy/security" from the
repo?
They are just a few test and it looks like no work has been done on them
since 2007.
Security Test are not run in the Groovy Gradle build since 20.03.2012. I
do not know if they ran in the old An
Hello everybody,
jars under "src/test/resources" are now gone.
-Pascal
Am 08.06.2015 um 22:07 schrieb Pascal Schumacher:
Hi Paul,
thanks for the feedback. :)
I have not looked into it yet, I was waiting for feedback.
My plan was to take the current jars, base-64 encode the binary their
con
I wrote a mail to core-lib-dev to get some feedback. That reflection and
getSimpleName combination looks like a JDK bug to me
Am 14.06.2015 16:54, schrieb Cédric Champeau:
2015-06-14 8:31 GMT+02:00 Jochen Theodorou mailto:blackd...@gmx.org>>:
Am 13.06.2015 21:41, schrieb Remi Forax:
Hi everybody,
I have to correct myself. Only the
ExtensionModuleTest#testThatModuleHasBeenLoaded test does not require
the jars. The other three tests correctly fail when the jars are not
present.
Sorry,
Pascal
Am 10.06.2015 um 20:57 schrieb Pascal Schumacher:
Hi everybody,
because of the
Ok so if we make those changes to 2.4.x as well, then I would suggest to
upgrade the wrapper too, because they come as a whole : those changes are
directly related to JDK 9 support and not needed otherwise.
2015-06-14 8:34 GMT+02:00 Jochen Theodorou :
> Am 13.06.2015 18:36, schrieb Cédric Champea
2015-06-14 8:31 GMT+02:00 Jochen Theodorou :
> Am 13.06.2015 21:41, schrieb Remi Forax:
> [...]
>
>> getSimpleName() now uses the InnerClasses attribute instead of parsing
>> the class name which was dubious:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-April/032733.html
>>
>
>
Thank you for the clarification!
2015-06-13 18:20 GMT+02:00 Cédric Champeau :
> Yes, because Gradle 2.4 doesn't support JDK 9.
>
> 2015-06-13 18:17 GMT+02:00 Benedikt Ritter :
>
>> Hello,
>>
>> has the change to gradle-wrapper.properties been made intentionally?
>>
>> Benedikt
>>
>> -- Fo
12 matches
Mail list logo
