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 <[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. >>
