[jira] [Comment Edited] (UIMA-2978) CustomResourceSpecifier has no support for resource meta data
[ https://issues.apache.org/jira/browse/UIMA-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=13678526#comment-13678526 ] Marshall Schor edited comment on UIMA-2978 at 10/12/16 9:45 PM: ConfigurableDataResourceSpecifier adds the ResourceMetaData, but it also adds the DataResource. What I'd like to have (any probably the issue should be renamed accordingly) is a ConfigurableResourceSpecifier (without data). I marked it as a bug, because the Resource interface specifies a getMetaData() method, so one should be able to assume (at least I did) that this should always filled by any specifier. Also, storing the configuration settings of a resource in the meta data should probably be preferred over having a second, less expressive parameter specification mechanism. Following that train of through one should probably be able to assume that any Resource is "configurable" and that a "ConfigurableResourceSpecified" wouldn't even be required as configurability should already be provided by "ResourceSpecifier". It's not release critical, but I thinks its major enough to think seriously about it (and it's the default). If there was a "normal", I'd have marked it as that, but the next lower level is "minor", which I think doesn't do it justice either. was (Author: rec): ConfigurableDataResourceSpecifier adds the ResourceMetaData, but it also adds the DataResource. What I'd like to have (any probably the issue should be renamed accordingly) is a ConfigurableResourceSpecifier (without data). I marked it as a bug, because the Resource interface specifies a getMetaData() method, so one should be able to assume (at least I did) that this should always filled by any specifier. Also, storing the configuration settings of a resource in the meta data should probably be preferred over having a second, less expressive parameter specification mechanism. Following that train of through one should probably be able to assume that any Resource is "configurable" and that a "ConfigurableResourceSpecified" wouldn't even be required as configurability should already be provided by "ResourceSpecifier". It's not release critical, but I thinks its major enough to thing seriously about it (and it's the default). If there was a "normal", I'd have marked it as that, but the next lower level is "minor", which I think doesn't do it justice either. > CustomResourceSpecifier has no support for resource meta data > - > > Key: UIMA-2978 > URL: https://issues.apache.org/jira/browse/UIMA-2978 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Richard Eckart de Castilho > Labels: Resources > > The CustomResourceSpecifier provides a way of defining new custom types of > Resources (e.g. *not* DataResources) which can be acquired via the > ResourceManager. > The CustomResourceSpecifier does not support the usual ResourceMetaData, > which includes support for the typical UIMA parameter configuration. It > supports only single-valued String parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (UIMA-2978) CustomResourceSpecifier has no support for resource meta data
[ https://issues.apache.org/jira/browse/UIMA-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=13678518#comment-13678518 ] Marshall Schor edited comment on UIMA-2978 at 10/12/16 9:43 PM: My guess is that this is as it was designed. UIMA has various categories of ResourceSpecifiers - one of which is the "ConfigurableDataResourceSpecifier, which adds "ResourceMetaData (which includes config param settings). But there are many other kinds (e.g. FileLanguageResourceSpecifier, FileResourceSpecifier, etc.) which don't have the ResourceMetaData field. I'm not sure why this is marked as a "bug" - is it more a request for an enhancement? What is the use case(s) for this, and how important is it to get a change here into the next release (I see it is marked "major" priority?)? was (Author: schor): My guess is that this is as it was designed. UIMA has various categories of ResourceSpecifiers - one of which is the "ConfigurableDataResrouceSpecifier, which adds "ResourceMetaData (which includes config param settings). But there are many other kinds (e.g. FileLanguageResourceSpecifier, FileResourceSpecifier, etc.) which don't have the ResourceMetaData field. I'm not sure why this is marked as a "bug" - is it more a request for an enhancement? What is the use case(s) for this, and how important is it to get a change here into the next release (I see it is marked "major" priority?)? > CustomResourceSpecifier has no support for resource meta data > - > > Key: UIMA-2978 > URL: https://issues.apache.org/jira/browse/UIMA-2978 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Richard Eckart de Castilho > Labels: Resources > > The CustomResourceSpecifier provides a way of defining new custom types of > Resources (e.g. *not* DataResources) which can be acquired via the > ResourceManager. > The CustomResourceSpecifier does not support the usual ResourceMetaData, > which includes support for the typical UIMA parameter configuration. It > supports only single-valued String parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (UIMA-2978) CustomResourceSpecifier has no support for resource meta data
[ https://issues.apache.org/jira/browse/UIMA-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678526#comment-13678526 ] Richard Eckart de Castilho edited comment on UIMA-2978 at 6/7/13 11:15 PM: --- ConfigurableDataResourceSpecifier adds the ResourceMetaData, but it also adds the DataResource. What I'd like to have (any probably the issue should be renamed accordingly) is a ConfigurableResourceSpecifier (without data). I marked it as a bug, because the Resource interface specifies a getMetaData() method, so one should be able to assume (at least I did) that this should always filled by any specifier. Also, storing the configuration settings of a resource in the meta data should probably be preferred over having a second, less expressive parameter specification mechanism. Following that train of through one should probably be able to assume that any Resource is configurable and that a ConfigurableResourceSpecified wouldn't even be required as configurability should already be provided by ResourceSpecifier. It's not release critical, but I thinks its major enough to thing seriously about it (and it's the default). If there was a normal, I'd have marked it as that, but the next lower level is minor, which I think doesn't do it justice either. was (Author: rec): ConfigurableDataResourceSpecifier adds the ResourceMetaData, but it also adds the DataResource. What I'd like to have (any probably the issue should be renamed accordingly) is a ConfigurableResourceSpecifier (without data). I marked it as a bug, because the Resource interface specifies a getMetaData() method, so one should be able to assume (at least I did) that this should always filled by any specifier. Also, storing the configuration settings of a resource in the meta data should probably be preferred over having a second, less expressive parameter specification mechanism. It's not release critical, but I thinks its major enough to thing seriously about it (and it's the default). If there was a normal, I'd have marked it as that, but the next lower level is minor, which I think doesn't go it justice either. CustomResourceSpecifier has no support for resource meta data - Key: UIMA-2978 URL: https://issues.apache.org/jira/browse/UIMA-2978 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Richard Eckart de Castilho The CustomResourceSpecifier provides a way of defining new custom types of Resources (e.g. *not* DataResources) which can be acquired via the ResourceManager. The CustomResourceSpecifier does not support the usual ResourceMetaData, which includes support for the typical UIMA parameter configuration. It supports only single-valued String parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
