uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: [VOTE] uimaj sdk 2.10.0 rc1
Date Tue, 04 Apr 2017 11:55:39 GMT
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