One more follow up question before I answer: is there a way to run a subset of tests without these present?
Thanks, Roman. On Mon, Jun 15, 2015 at 1:17 PM, Cédric Champeau <cedric.champ...@gmail.com> wrote: > 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 >> >> >
