incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <>
Subject Re: Question about jar files in svn.
Date Thu, 19 Dec 2013 18:40:22 GMT
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

- Henry

On Thu, Dec 19, 2013 at 10:34 AM, sebb <> wrote:
> On 19 December 2013 18:26, Henry Saputra <> 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 <> wrote:
>>> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <> wrote:
>>>> We’re having a discussion over in that was triggered
>>>> 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:
>>>> 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:
>>>     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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message