uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] uimaj sdk 2.10.0 rc1
Date Tue, 04 Apr 2017 14:55:30 GMT
In this case, I would be fine not holding up 2.10.0 release, along the lines
Richard suggested, stating that the loading of external overrides from the
classpath (new this release) will be changing in the next release.

Burn, if you agree, please consider voting on the release :-)

-Marshall


On 4/4/2017 10:04 AM, Burn Lewis wrote:
> Class-/data-path loading of external settings files is not in 2.9.0 ... it
> is new in 2.10.0.
>
> Burn
>
> On Tue, Apr 4, 2017 at 9:54 AM, Marshall Schor <msa@schor.com> wrote:
>
>> just to be clear, this last discussion thread topic about changing the
>> interpretation of -DUimaEternalOverrides would result in a breaking change
>> from
>> 2.9.0 - that is - this is already in the 2.9.0 implementation, is this
>> correct?
>>
>> -Marshall
>>
>>
>> On 4/4/2017 8:35 AM, Burn Lewis wrote:
>>> Certainly.  I don't want to rush this change through without discussion.
>>> One drawback to this proposed syntax is that it could break an existing
>>> application .... if a settings file was specified as *"foo.settings"*
>> then
>>> instead of being loaded from the current directory the class path would
>> be
>>> searched for *"foo.settings.settings"*.  It would have to be changed to
>>> *"./foo.settings"* to get the original behavior.
>>>
>>> Burn
>>>
>>> On Tue, Apr 4, 2017 at 7:55 AM, Richard Eckart de Castilho <
>> rec@apache.org>
>>> wrote:
>>>
>>>> Would you be ok with releasing RC1 with the note that this external
>>>> overrides
>>>> behavior will be changed in the next release *without* introducing a
>> flag
>>>> that
>>>> restore the RC1 behavior (i.e. a potentially breaking change)?
>>>>
>>>> -- Richard
>>>>
>>>>> On 04.04.2017, at 00:32, Burn Lewis <burnlewis@gmail.com> wrote:
>>>>>
>>>>> The other issue is what I now believe is a poor design choice I made
in
>>>>> Jira 5208 which lets an external overrides settings file be loaded from
>>>> the
>>>>> class path or data path.  Currently if the file name is relative but
>> not
>>>>> found in the filesystem the class path and data path are searched.  A
>>>>> cleaner design would be to follow the same convention used for
>> importing
>>>>> descriptors by name, i.e. use the java class notation to indicate that
>>>> the
>>>>> class path & data path must be searched (after replacing "." by "/"
and
>>>>> adding ".settings".)  The presence of a "/" in a file name would imply
>> a
>>>>> filesystem lookup.
>>>>>
>>>>> Thus a specification of *-DUimaEternalOverries=abc/
>>>> test.settings,d.e.f.test
>>>>> *would load the first file from the filesystem and load the second as
>>>>> *d/e/f/test.settings* from the class path or data path.  The current
>>>>> implementation makes it possible to silently change a program's
>>>> parameters
>>>>> by merely adding a file to the filesystem that replaces one that is
>>>> usually
>>>>> loaded from the class path ... perhaps not a desirable feature.
>>>>>
>>>>> Since this is not a severe problem I don't feel I can justify voting
>> rc1
>>>>> down so I'll hold off until I have a potential fix, and will wait for
>>>> other
>>>>> comments.
>>


Mime
View raw message