My understanding of the link I posted way back is that the source package cannot contain compiled output that will be executed by the customer. IMO, whether it is "external" or not doesn't matter. The JAR used by the Compress tests is hopefully just data, not some part of its functionality.
On 12/19/13 10:40 AM, "Henry Saputra" <henry.sapu...@gmail.com> wrote: >Ah I see. > >So the point of concern is the "external" jars, but jars that are >generated by the project itself (for example for tests) should be >fine? > >- Henry > >On Thu, Dec 19, 2013 at 10:34 AM, sebb <seb...@gmail.com> wrote: >> On 19 December 2013 18:26, Henry Saputra <henry.sapu...@gmail.com> >>wrote: >>> But at the end, when a podling prepare a release there should not >>> include jar files as part of the source release artifacts to be VOTED >>> on, is this correct? >> >> I think that depends on what the jar files are. >> For example. Apache Commons Compress includes some jar files in SVN >> and the source release as part of the test data. >> >> But I would not expect to find "external" jar files in the source >>release. >> >>> - Henry >>> >>> On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey >>><mar...@rectangular.com> wrote: >>>> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <tras...@stratuscom.com> >>>>wrote: >>>>> We¹re having a discussion over in d...@river.apache.org that was >>>>>triggered by >>>>> the recent discussion here about the Spark podling release. >>>> >>>> The River discussions seem to be playing out productively. Here are >>>>links for >>>> other people who may be interested: >>>> >>>> https://issues.apache.org/jira/browse/RIVER-432 >>>> http://markmail.org/thread/abppti56ipnhnnfy >>>> >>>>> To be more specific, there doesn¹t seem to be any doubt that jars >>>>>shouldn¹t >>>>> be included in source release packages, but would it be fair to say >>>>>that >>>>> they should also not be in the svn? >>>> >>>> My understanding is that it is fine to store jars in version control >>>>outside >>>> of the main source tree, analogous to providing a separate "-deps" >>>>download. >>>> Between that and technical solutions which download deps on the fly >>>>such as >>>> Ivy and Maven, I think that renders the question about whether >>>>binaries can >>>> reside in the main source tree within version control moot. >>>> >>>> But there's no strictly enforced policy AFAIK because we discourage >>>>people >>>> from considering our source control repositories distribution points. >>>> (Note >>>> to podlings: this is why we make links to source control only >>>>available >>>> through the developer portions of our websites, etc.) That way we >>>>don't have >>>> to be rigid about enforcing the policies which apply to releases at >>>>every >>>> single commit point, even as we make best efforts to keep our trees >>>>clean. >>>> >>>> FWIW, the same principles which give us a measure of flexibility >>>>about LICENSE >>>> and NOTICE in version control could arguably apply to jar files as >>>>well. >>>> Here's Board member Doug Cutting back in September on >>>>legal-discuss@apache: >>>> >>>> http://s.apache.org/GNP >>>> >>>> I think perhaps you're looking for clear lines where things are >>>> actually a bit fuzzy. Certainly releases are official >>>>distributions >>>> and need LICENSE and NOTICE files. That line is clear. On the >>>>other >>>> hand, we try to discourage folks from thinking that source >>>>control is >>>> a distribution. Rather we wish it to be considered our shared >>>> workspace, containing works in progress, not yet always ready for >>>> distribution to folks outside the foundation. But, since we work >>>>in >>>> public, folks from outside the foundation can see our shared >>>>workspace >>>> and might occasionally mistake it for an official distribution. >>>>We'd >>>> like them to still see a LICENSE and NOTICE file. So it's not a >>>> hard-and-fast requirement that every tree that can possibly be >>>>checked >>>> out have a LICENSE and NOTICE file at its root, but it's a good >>>> practice for those trees that are likely to be checked out have >>>>them, >>>> so that folks who might consume them are well informed. >>>> >>>> Again, policy flexibility with respect to version control becomes >>>>academic if >>>> you can restructure the build. Nevertheless, I hope that this >>>>additional >>>> background is helpful for River's ongoing discussions. >>>> >>>> Cheers, >>>> >>>> Marvin Humphrey >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
