[ 
https://issues.apache.org/jira/browse/UIMA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707741#comment-13707741
 ] 

Marshall Schor edited comment on UIMA-2903 at 10/12/16 8:36 PM:
----------------------------------------------------------------

I think that the top level abstraction that informed the current UIMA design 
was something like:

0) Goal: support the effective putting-together-of-parts that are independently 
developed, such that they run together efficiently, and are configurable.

1) UIMA has a lifecycle in which some details are resolved at "launch-time":  
parameters are obtained, type systems are merged, external resources are 
loaded.  

2) Following this, there are one or more "initialize" calls done on many of the 
loaded things.  Note that this call could be done multiple times for the same 
resource; see 
http://uima.apache.org/d/uimaj-2.4.0/tutorials_and_users_guides.html#ugr.tug.aae.contract_for_annotator_methods

3) Some motivation for external resources managed by UIMA is given here: 
http://uima.apache.org/d/uimaj-2.4.0/tutorials_and_users_guides.html#ugr.tug.aae.accessing_external_resource_files
 .

I don't believe that any thought was given to scenarios where one UIMA-managed 
"Resource" would directly  "fetch" (does this mean "load"?) another one, as 
this (on the surface) would seem to not fit with the motivations for this. 

Is this the use case behind this request?  If so, it would help me understand 
things if some scenarios where this is wanted are described, and why the 
alternative of using UIMA's external resources declarations and bindings 
mechanism isn't used.


was (Author: schor):
I think that the top level abstraction that informed the current UIMA design 
was something like:

0) Goal: support the effective putting-together-of-parts that are independently 
developed, such that they run together efficiently, and are configurable.

1) UIMA has a lifecycle in which some details are resolved at "launch-time":  
parameters are obtained, type systems are merged, external resources are 
loaded.  

2) Following this, there are one or more an "initialize" call done on many of 
the loaded things.  Note that this call could be done multiple times for the 
same resource; see 
http://uima.apache.org/d/uimaj-2.4.0/tutorials_and_users_guides.html#ugr.tug.aae.contract_for_annotator_methods

3) Some motivation for external resources managed by UIMA is given here: 
http://uima.apache.org/d/uimaj-2.4.0/tutorials_and_users_guides.html#ugr.tug.aae.accessing_external_resource_files
 .

I don't believe that any thought was given to scenarios where one UIMA-managed 
"Resource" would directly  "fetch" (does this mean "load"?) another one, as 
this (on the surface) would seem to not fit with the motivations for this. 

Is this the use case behind this request?  If so, it would help me understand 
things if some scenarios where this is wanted are described, and why the 
alternative of using UIMA's external resources declarations and bindings 
mechanism isn't used.

> List resources in a ResourceManager / remove hack in uimaFIT
> ------------------------------------------------------------
>
>                 Key: UIMA-2903
>                 URL: https://issues.apache.org/jira/browse/UIMA-2903
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework, uimaFIT
>            Reporter: Richard Eckart de Castilho
>              Labels: Resources
>             Fix For: 2.3.0uimaFIT
>
>
> uimaFIT currently gets a list of resources that are registered with a 
> ResourceManager. This is handled via accessing the "mResourceMap" field of 
> the ResourceManager_impl class via reflection. Obviously, this is not a good 
> solution.
> uimaFIT iterates over the resources in the context while initializing 
> resources that are referenced from other external resources.
> There may be two options:
> # add a listResources() method to the ResourceManager interface
> # get the resources that need to be initialized in some other way. I don't 
> know if there is one, because if there was, I'd probably have used it. 
> Looking at the @ExternalResource annotations doesn't help, because they do 
> not give informations about the resource bindings. The bindings are only 
> available in the ResourceManager, which takes us back to 1).
> Would it be possible to add a method allowing to list the resource bindings 
> registered in a ResourceManager to the ResourceManager interface?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to