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