groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: Jars in disguise (was: [VOTE] Release Apache Groovy 2.4.4-incubating)
Date Mon, 15 Jun 2015 17:31:07 GMT
On Mon, Jun 15, 2015 at 12:12 AM, Bertrand Delacretaz
<bdelacretaz@apache.org> wrote:
> Hi,
>
> On Sun, Jun 14, 2015 at 8:43 PM, Pascal Schumacher
> <pascalschumacher@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.

+1.

> 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.

It is not even that. It is the issue that anytime you allow a binary artifact
as a requirement you take a huge step away from bootstrapping your
system from source. To me this is a super important requirement, but
then again I come from OS UNIX distribution building background.

Thanks,
Roman.

Mime
View raw message