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 13:54:10 GMT
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?


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.

View raw message