incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [Code] issue 118623: Update Rhino from 1.5R5 to 1.7R3
Date Tue, 29 Nov 2011 16:17:52 GMT
On Tue, Nov 29, 2011 at 11:07 AM, Andre Fischer <af@a-w-f.de> wrote:
>
>
> On 29.11.2011 13:08, Rob Weir wrote:
>>
>> On Tue, Nov 29, 2011 at 6:11 AM, Andre Fischer<af@a-w-f.de>  wrote:
>>>
>>> Hi all,
>>>
>>> I need advice regarding license headers.
>>>
>>> The upgrade of rhino to version 1.7 will integrate a file
>>> (OfficeScriptInfo.java) that previously existed only in a patch that was
>>> applied to version 1.5 source code before building.  This file still has
>>> the
>>> old license.  The patch file itself is part of the SGA.
>>>
>>
>> So the entire OfficeScriptInfo.java was included in a patch, and that
>> patch was included in the SGA?  If that is true, then I believe we may
>> update the license header in the source file.
>>
>> Think of it this way:  The SGA is what puts these files under ALv2.
>> Updating the license header is how we document this fact, so it is
>> clear to downstream consumers exactly what files are under ALv2.
>
>
> Good, I was hoping for this answer.
>
> And I have another question.  Can/should we download the source or even the
> binaries (keep in mind that rhino is a Java library, so the binary is a JAR
> file) directly from the mozilla servers or should we update the rhino tar
> ball in ext_sources?
>

I'm working on another Apache podling (ODF Toolkit) where we use
Maven.  So no third party components are stored in SVN.  JAR's are
downloaded at build time.  That is the Maven model.  So that is
certainly permitted.

IMHO, I'd look at the stability of the host.  If we have a dependency
on a long-established, well-known, widely-used open source component
that is not tremendously large, then we could safely download it it
build time.  (Assuming the license is compatible, of course).

But if it is a component that we worry might disappear tomorrow, or
the host is not very attentive to preserving stability of URL
references, or they commonly delete old binaries when updating their
component,  then having a copy in SVN could be a good idea.

The idea should be (I believe) to support some sort of release policy
where we have something like "Long term stable" releases as well as
more frequent feature releases.  For an LTS release we would want to
be able to spin a new maintenance release 18 months from now.  What do
we need to do to be sure that everything we depend on is still there?

That's my personal opinion.


-Rob

> Regards,
> Andre
>
>
>>
>> -Rob
>>
>>> My question is how to handle this file?  Change the license on my own?
>>> Ask
>>> Andrew Rist to do it?
>>>
>>> Regards,
>>> Andre
>>>
>>>
>>> On 25.11.2011 15:44, Tsutomu Uchino wrote:
>>>>
>>>>
>>>> Hi Andre,
>>>>
>>>> 2011/11/25 Andre Fischer<af@a-w-f.de>:
>>>>>
>>>>>
>>>>> Hi Tsutomu,
>>>>>
>>>>> On 25.11.2011 13:08, Tsutomu Uchino wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Andre,
>>>>>>
>>>>>> Yesterday I got a suggestion about MPL license from Pedro. But it
is
>>>>>> clear
>>>>>> now.
>>>>>> I have already reopned the issue.
>>>>>
>>>>>
>>>>>
>>>>> Ah, very good :-)
>>>>>
>>>>>>
>>>>>> Additionally, I noticed about license issue we need to add configure
>>>>>> options to switch Rhino enabled or disabled.
>>>>>
>>>>>
>>>>>
>>>>> I can do that if you like.  There are a number of libraries that have
>>>>> to
>>>>> get
>>>>> a special treatment, not just rhino.  I will start to work on that,
as
>>>>> soon
>>>>> the category-x code is removed.
>>>>
>>>>
>>>> Thank you for your work. I think I can do it in short time, my
>>>> knowledge about the building process is not enough for the task.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Andre
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Tsutomu

Mime
View raw message