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