I guess I'm the opposite: I think it is better in the long run to be more explicit about when you want external override settings loaded from the classpath/datapath, rather than relying on some convention which might also need som -D override flag for some cases.
That way, things are less "hidden", or "only known to those in-the-know", etc, and instead are more explicit (and the rules are simpler too). My 2 cents. -Marshall On 4/20/2017 2:35 PM, Burn Lewis wrote: > I mean that I'd prefer no prefixes ... just the presence or absence of /'s. > > On Thu, Apr 20, 2017 at 2:29 PM, Marshall Schor <[email protected]> wrote: > >> >> On 4/20/2017 2:20 PM, Burn Lewis wrote: >>> Another suggestion is to use a schema-like prefix ...* name: *or an >>> optional *file:* >> Either way would be fine with me. >>> Ideally I would prefer "the names of file resources contain file path >>> separators, while path resources only dots." >>> But for backward compatibility we need to treat entries such as >>> foo.settings as files ... but this back-level support could be enabled by >>> an environment variable. >> I don't understand why this would be needed, if you required that name: or >> name= >> prefix be there for the classpath/datapath choice? Then if it wasn't >> there, it >> would be the file system choice, and it wouldn't matter if there were "/" >> there >> or not? >> >> -Marshall >>> ~Burn >>> >>> >>> On Thu, Apr 20, 2017 at 1:53 PM, Marshall Schor <[email protected]> wrote: >>> >>>> On 4/19/2017 4:20 PM, Burn Lewis wrote: >>>>> In UIMA 2.10.0 support was added for loading external override settings >>>>> from the classpath or datapath, but the approach chosen introduced an >>>>> ambiguity >>>> ambiguity maybe not quite the right idea. If the order of looking is >> well >>>> defined, then what we have is a spec which has a non-ambiguous >>>> interpretation, >>>> but that interpretation depends on the run-time existence (or not) of >>>> things. >>>> >>>> So, I think the goal is to make this more explicit, instead of implicit. >>>> >>>>> by looking first in the filesystem and then in the class path or >>>>> datapath. A better approach would be to use a syntax that clearly >>>>> indicates whether to search the filesystem, or to search the classpath >> & >>>>> datapath. >>>> Sounds like a good idea, and in line with many other tradeoffs done in >>>> UIMA in >>>> favor of helping users to avoid mistakes. The mistake here would be >>>> expecting >>>> to get the external overrides from the classpath, for example, but >>>> "accidentally" having a file system file that unintentionally starts >>>> overriding >>>> this (I'm assuming that file system things override classpath things. >> If >>>> that's >>>> backwards, just reverse the example :-) ). >>>> >>>>> We could represent path resources using the Java-style dotted name >> syntax >>>>> as is used for UIMA imports by name. The dots would be replaced by >> file >>>>> path separators and the suffix ".settings" appended before searching >> the >>>>> paths. Ideally the presence of a slash would indicate a file resource, >>>> but >>>>> in case existing applications are using a simple relative filename we >>>> could >>>>> also check for the presence of a ".settings" suffix. >>>>> >>>>> Another approach would be to copy the import convention and also allow >> a >>>>> name or location attribute. So the comma-separated elements could be a >>>>> filename, or location=filename, or name=dotted-name. >>>>> >>>>> The documentation could be: >>>>> >>>>> The value of the property must be a list of resource names, each >>>> separated >>>>> by a single comma. The name can be a filename, or a Java-style dotted >>>> name >>>>> loaded from the class path or data path. Dots are replaced by file >> path >>>>> separators and the suffix ".settings" is appended. Note that if that >>>>> suffix is already present the resource is assumed to be a file. >>>>> e.g. -DUimaExternalOverrides=/data/file1.settings,org.foo.bar. >>>> file2.settings >>>>> or >>>>> >>>>> The value of the property must be a list of resources, each separated >> by >>>> a >>>>> single comma. The resource can be specified as a filename, or as >>>>> name=dotted-name, or as location=filename. The dotted-name resources >> are >>>>> loaded from the class path or data path after replacing dots by file >> path >>>>> separators and appending the suffix ".settings". >>>>> e.g. >>>>> -DUimaExternalOverrides=/data/file1.settings,name=org.foo. >>>> bar,location=file2.settings >>>>> Comments and better/different suggestions welcome! >>>> One other criteria to consider: can the most likely usage already >>>> existing, be >>>> made backward compatible? >>>> >>>> I kind of like the name= style (indicating to get it from the >>>> classpath/datapath), since that is the same as already existing syntax >> for >>>> imports. >>>> >>>> For backwards compatibility, I would allow the location=xxxx or just >> xxxx >>>> as it >>>> is today. >>>> >>>> -Marshall >>>> >>
