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 <[email protected]> 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.
