groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Jars in disguise (was: [VOTE] Release Apache Groovy 2.4.4-incubating)
Date Tue, 16 Jun 2015 01:45:13 GMT

I polled general@incubator.a.o <mailto:general@incubator.a.o> a few years ago on  a
similar topic.  Discussion at:
http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C24F4A019-B30C-4CFA-A00B-F792A22DEACB@stratuscom.com%3E
<http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C24F4A019-B30C-4CFA-A00B-F792A22DEACB@stratuscom.com%3E>

Cheers,

Greg Trasuk

> On Jun 15, 2015, at 9:36 PM, Greg Trasuk <trasukg@stratuscom.com> wrote:
> 
> 
> 
> 
>> On Jun 15, 2015, at 7:02 PM, David Nalley <david@gnsa.us> wrote:
>> 
>> On Mon, Jun 15, 2015 at 4:17 PM, Cédric Champeau
>> <cedric.champeau@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
>>> 
>> 
>> I don't know that your understanding agrees with the Incubator's
>> stance on binaries in releases. I'd at a minimum start a proactive
>> discussion on general@., and I would expect a lot of resistance to
>> binaries in a source release.
>> 
>> —David
> 
> Imagine if there were an incubator project that was an image-processing library, and
part of the test was to perform an averaging function on a test image (e.g. of a 60%-gray
image) and see if the result came to 60%.
> 
> The test image would be a “binary” (e.g. a PNG), right?  Would we insist that the
test be removed because having it would mean packaging a “binary” in the source distribution?
 That would seem not to make much sense.  
> 
> We would certainly want to make sure that the image file in question was licensed appropriately
for distribution, but if you have a package whose functionality is processing binary images,
then it would make sense that you’d need binary images in the test resources to prove out
the package.
> 
> Similarly, if part of Groovy’s job is to read jar files, then it certainly makes sense
that you might need jar files in the test resources.
> 
> Obviously, if you were shipping a jar that was part of the final executable environment,
that would be unacceptable in a source distribution.  But  a sample artifact used as a test
input should be fine, so long as it’s obvious that it’s a test resource, and there’s
no issue with giving out copies of it.
> 
> 
> Cheers,
> 
> Greg Trasuk
> 


Mime
View raw message