My understanding is that since those jars are for tests, it is OK to keep them as long as we:
- have a Rat rule that explicitly states why those jars are there - have a JIRA ticket that we can point people at when they ask 2015-06-15 21:01 GMT+02:00 Pascal Schumacher <pascalschumac...@gmx.net>: > I reverted, but you could have told me last monday (when I asked in this > thread). > > > Am 15.06.2015 um 09:12 schrieb Bertrand Delacretaz: > >> Hi, >> >> On Sun, Jun 14, 2015 at 8:43 PM, Pascal Schumacher >> <pascalschumac...@gmx.net> wrote: >> >>> ...jars under "src/test/resources" are now gone.... >>> >> Encoding those jars in base64 as in [1] does not mean they are gone, >> they're just encoded in a different way. >> >> If those jars are useful for testing, it's much preferable IMO to have >> them as jar files to make it obvious that the source code does contain >> binaries. Maybe isolate them in a single folder and include a readme >> file in their which explains why they are useful and lists their sha1 >> digests so people can detect any changes to them. >> >> That code says >> >> // Apache License does not allow jars/binaries in the source >>> >> but avoiding binaries in Apache releases has nothing to do with the >> Apache License, it's just that there's usually no way for someone to >> verify that a lone binary file has not been tampered with, and we want >> our users to be able to trust what we release. Hiding stuff in source >> code does not look very trustful to me. >> >> -Bertrand >> >> [1] >> https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=blob;f=src/test/org/codehaus/groovy/runtime/m12n/ExtensionModuleHelperForTests.groovy;h=01fb34e1fcfb6ed84bbc1630d12218e6dfd566d4;hb=1bb5c5a9 >> > >
