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
