Implementing as a post-processing step does sound right. It would be nice if the logic was in the core so that every execution engine could just make a single method call. This would also allow an execution environment to use separate properties files when instantiating multiple AEs, as for example when the UIMA-AS client API does in process deployment of services.
Thanks, Eddie On Tue, Apr 5, 2011 at 5:57 PM, Richard Eckart de Castilho <[email protected]> wrote: > It sounds like this could easily be implemented as a post-processing step on > an (aggregate) descriptor. > > 1) load aggregate (descriptor) - AnalysisEngineDescriptor desc = ... > 2) load properties - Properties config = ... > 3) set configuration parameters in descriptor from values used in properties > - applyConfiguration(desc, properties); > > Such a feature could then be integrated into an execution engine like the CPE > or UIMA-AS. > > Is that what you had in mind or did you think about a deeper integration into > UIMA? > > Cheers, > > Richard > > Am 05.04.2011 um 22:44 schrieb Eddie Epstein: > >> We've also been discussing the need for a new mechanism to >> set configuration values outside of descriptors. A rough idea is >> to use Java properties with a notation that allows specification >> of a parameter value at any level in a nested aggregate. >> >> For example, a single property file specified at runtime could >> define all "non-default" parameter values in the aggregate. >> This mechanism would bypass the need to create override >> parameters for intermediate aggregates in order for a top >> level parameter to specify a parameter value for a delegate >> several layers below. >> >> Parameter overrides would still work, so that a single setting >> at an upper level could specify the value to use in multiple >> delegates. >> >> This approach would allow descriptors to become independent >> of "application" version changes due to parameter value changes. >> >> Eddie >> >> On Tue, Apr 5, 2011 at 1:36 PM, Jörn Kottmann <[email protected]> wrote: >>> On 4/5/11 6:56 PM, Richard Eckart de Castilho wrote: >>>> >>>> Am 05.04.2011 um 18:34 schrieb Jörn Kottmann: >>>> >>>>> Yes, if you use UimaFIT the AE cannot run without it, which makes it >>>>> difficult to use it in various solutions >>>>> which use our APIs to embed an AE e.g. like the new Solr integration >>>>> does, or am I mistaken? >>>> >>>> You can use uimaFIT factories for testing without using annotations and >>>> without introducing a runtime dependency on uimaFIT. >>>> >>>> You can use uimaFIT annotations and uimaFIT's context injection helper and >>>> still instantiate or run components in any manner you like. Your code will >>>> not notice the presence of uimaFIT at all. However, it becomes a >>>> runtime-dependency in this case. Since uimaFIT is licensed under Apache >>>> 2.0, >>>> it should be compatible with UIMA/UIMA-AS at that point. >>>> >>>> Does this address your concerns? >>>> >>> Yes mostly, but I still believe that we should have support for defining >>> the configuration parameters and optionally injecting the >>> values inside the framework itself. >>> >>> Jörn >>> > > Richard Eckart de Castilho > > -- > ------------------------------------------------------------------- > Richard Eckart de Castilho > Technical Lead > Ubiquitous Knowledge Processing Lab > FB 20 Computer Science Department > Technische Universität Darmstadt > Hochschulstr. 10, D-64289 Darmstadt, Germany > phone +49 (6151) 16-7477, fax -5455, room S2/02/E225 > [email protected] > www.ukp.tu-darmstadt.de > ------------------------------------------------------------------- > > > > > >
