Hi Richard, Thanks for the writeup. I'm starting to think about this...
One thing that UIMA is "about" is the creating of compose-able components, and supporting different skill sets / roles for users of the framework. Re: this last point, we have a role called "assembler" in mind, someone who may not know any details of programming languages (annotators might be developed in Java, or C++, or ...), but can do some xml editing (perhaps with a form-based editor), and put together and configure a pipeline of annotators, developed by others. This kind of use case leads to the posture where we have externalized configuration parameters and settings, in XML, outside of the annotator implementation. I agree with the general observation that it's nice to writing things down once (don't repeat yourself), and our current approach for configuration parameters does fall short I think, in this regard; you have to write them in XML and then also write them in Java... (or C++ ...). I'm thinking (outloud) here of another kind of approach. Suppose we keep the idea that the main "place" for parameter definitions / settings, is in the XML. Perhaps we could use injection ideas + Java annotations to simplify the Java code. Here's how it might work. You would define the parameters, etc., externally in the XML, as is now done. But in the Java code, you would write something like // this form if the name of the external parm differs from the variable name @uimaParameter(ExternalParmName1) String myStringParm; // this form if the name of the external parm is the same as the variable name @uimaParameter int myIntParam; etc. And then we would have the normal UIMA initialize code path, before it called initialize, find the @uimaParameter items and set them from the XML parameter settings. -Marshall On 10/18/2011 3:21 PM, Richard Eckart de Castilho wrote: > Hello Jörn, > > I have added a page with some information about the context injection > mechanism in uimaFIT to the uimaFIT wiki. The intention is to > > - illustrate how it currently works > - point out the currently unresolved issues and feature ideas > - provide some information on related DI mechanisms (e.g. JSR 250) > > Maybe you could have a look at that and tell me if additional information is > required. > > Before an integration into the core UIMA framework I think it should be > discussed whether custom DI annotations should be used (as currently done in > uimaFIT), or if UIMA should support use JSR 250, or both since JSR 250 does > not cover all our needs. > > Also, I think the open some of the open issues listed on the page should be > resolved before an integration. > > It would be great if you could have a look at the page and tell me if that is > a suitable format for the desired specification or at least a starting point > for discussions. > > http://code.google.com/p/uimafit/wiki/ContextInjection > > Best, > > Richard > > Am 11.10.2011 um 22:11 schrieb Jörn Kottmann: > >> On 10/11/11 9:31 PM, Richard Eckart de Castilho wrote: >>> Am 06.10.2011 um 18:31 schrieb Jörn Kottmann: >>> >>>>> On 10/6/11 5:47 PM, Richard Eckart de Castilho wrote: >>>>>>> As a short update: there is a generally positive tenor towards this >>>>>>> amongst the uimaFIT developers. I'll draft up an action plan, discuss >>>>>>> that with my the others and afterwards present it here. >>>>>>> >>>>>>> Be patient with me though;) >>>>> Regards the AE Java annotation part I believe we should work out a >>>>> proposal which >>>>> describes how to implement it in the UIMA core framework. Then it is >>>>> easier to get consensus on it. >>> That sounds reasonable. What form do you suggest that proposal should take? >> I suggest that we write it down in a wiki page in a similar style like >> it was done >> for other proposals which are already in our wiki. >> >> Jörn
