On 19 December 2013 18:57, Alex Harui <aha...@adobe.com> wrote: > 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.
Yes, the jars are test data. > 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? Again, that's ambiguous. I would not expect to find jars of the project source in source releases. Note that the Compress test jars were manually created on various different systems. >> >>- 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
