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