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 >
