I haven't checked all the possibilities but for some of these it might
not be appropriate. We wanted to not just check that Groovy's methods
could round-trip but that they matched what the rest of the world
was using - so you'd need to use a third-party mechanism to create
the jars. But this might not apply in each case - just some of them
from memory. I'd have to go through each one by one. Just wanting
to minimize wasted time - but feel free to dive in and report
otherwise once you have been through the details - it's been quite
a while since we created those artifacts.
Cheers, Paul.
On 9/06/2015 2:16 AM, Pascal Schumacher wrote:
Am 08.06.2015 um 15:50 schrieb Emmanuel Lécharny:
3) The source release contains the following binaries (along with
other things like images which are ok), we need to clarify whether
they are required and what makes them safe to be included, if that's
the case:
./security/GroovyJarTest.jar
./security/groovykeys
./src/bin/groovy.icns
./src/test-resources/jars/module-test/module-test/1.0.7225-test/module-test-1.0.7225-test.jar
./src/test-resources/jars/module-test/module-test/1.2-test/module-test-1.2-test.jar
The best here would be to explain in the rat config why those files are
excluded. For .icns, it's quite obvious, I can understand that the jars
are test jars (ie, used to control that some part of teh Groovy API is
handling jars correctly).
We could also let the test create the files they require (e.g. from
base-64-encoded strings for the jars).
I can do the work if we agree to follow this approach.
-Pascal
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
