incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
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 <aharui@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.saputra@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 <sebbaz@gmail.com> wrote:
>>> On 19 December 2013 18:26, Henry Saputra <henry.saputra@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
>>>><marvin@rectangular.com> wrote:
>>>>> On Wed, Dec 18, 2013 at 7:45 PM, Greg Trasuk <trasukg@stratuscom.com>
>>>>>wrote:
>>>>>> We¹re having a discussion over in dev@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-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message