All I can say to that is that it is atypical of every other project I contribute to.
A release requires that you have a distribution that contains the buildable source. Typically that is package as a gzipped tar and/or a zip. Most projects also create a binary distribution that contains the jars, scripts and other items necessary to run or use what they are distributing. Many projects also distribute the source as a jar packaged by Maven as an artifact (IIRC the Maven Release plugin does this by default). This jar is useful as it can be automatically downloaded and used in IDEs when developers are writing code that uses the projects artifacts as a dependency and they want to see the code or debug into it. I'm really not sure what the value is in having the source packaged inside the binary distribution. The README is enough to let the consumer know it is open source and the source distribution is sitting in the same directory as the binary distribution. Ralph On Jun 27, 2012, at 5:54 PM, Mike Percy wrote: > The source is there so that people that download the binary know that Flume > is open source, and can even build it from the binary distro. > > Mike > > > On Wednesday, June 27, 2012 at 5:47 PM, Ralph Goers wrote: > >> I agree, but why is the source code in the binary distribution. That is what >> the source distribution is for. >> >> Ralph >> >> On Jun 27, 2012, at 5:44 PM, Hari Shreedharan wrote: >> >>> Hi Ralph, >>> >>> The target folder from flume-ng-tests will be removed when FLUME-1317 gets >>> committed. I am fairly sure this is what makes the tar very large, not the >>> source code. >>> >>> Thanks, >>> Hari >>> >>> -- >>> Hari Shreedharan >>> >>> >>> On Wednesday, June 27, 2012 at 5:28 PM, Ralph Goers wrote: >>> >>>> Why does the distribution tar contain source code? >>>> >>>> Why does the distribution contain flume-ng-tests/target and everything >>>> underneath that? >>>> >>>> These two things make the distribution very large and are making the Flume >>>> build excessively long since the integration tests untar them. For >>>> example, on my Mac TestRPCClient took 447 seconds (over 7 minutes). I ran >>>> a jstack on it and found that most of the time is spent in readBytes >>>> untarring the distribution. >>>> >>>> Ralph > >
