incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Question about jar files in svn.
Date Thu, 19 Dec 2013 19:41:52 GMT
On 19 December 2013 18:57, Alex Harui <> 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" <> 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

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 <> wrote:
>>> On 19 December 2013 18:26, Henry Saputra <>
>>>> 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
>>>> - Henry
>>>> On Thu, Dec 19, 2013 at 9:21 AM, Marvin Humphrey
>>>><> wrote:
>>>>> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <>
>>>>>> We¹re having a discussion over in 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:
>>>>>> To be more specific, there doesn¹t seem to be any doubt that jars
>>>>>> be included in source release packages, but would it be fair to say
>>>>>> they should also not be in the svn?
>>>>> My understanding is that it is fine to store jars in version control
>>>>> of the main source tree, analogous to providing a separate "-deps"
>>>>> 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
>>>>> from considering our source control repositories distribution points.
>>>>> (Note
>>>>> to podlings: this is why we make links to source control only
>>>>> 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
>>>>> single commit point, even as we make best efforts to keep our trees
>>>>> 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
>>>>> Here's Board member Doug Cutting back in September on
>>>>>     I think perhaps you're looking for clear lines where things are
>>>>>     actually a bit fuzzy.  Certainly releases are official
>>>>>     and need LICENSE and NOTICE files.  That line is clear.  On the
>>>>>     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
>>>>>     public, folks from outside the foundation can see our shared
>>>>>     and might occasionally mistake it for an official distribution.
>>>>>     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
>>>>>     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
>>>>>     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
>>>>> 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:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message