uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaroslaw Cwiklik <uim...@gmail.com>
Subject Re: Working on a new API to enable creation of UIMA AS deployment descriptors programmatically
Date Tue, 05 Apr 2011 16:31:31 GMT
Jorn, not sure I quite understand your comment. UimaFIT already provides
java annotations to configure
UIMA components via:


 Can you clarify your point?


On Tue, Apr 5, 2011 at 12:02 PM, Jörn Kottmann <kottmann@gmail.com> wrote:

> On 4/5/11 5:38 PM, Jaroslaw Cwiklik wrote:
>> UIMA AS extended test suite has become quite large. Each JUnit test
>> requires
>> one or more xml deployment descriptor to run. A lot of these static xml
>> descriptors are the same except for a few config parameters that change
>> error handling, scaleout, queue name, etc. There are about 200 xml files
>> already and this list keeps growing. This is becoming annoying having to
>> create static xml file for every test. Instead I propose creating a
>> Factory
>> object to enable each JUnit test to dynamically create and configure
>> deployment descriptors it needs. I would use Apache XMLBeans to create xml
>> backing java beans and factories which will be generated from UIMA AS
>> deployment descriptor xml schema. I would provide a java wrapper around
>> generated XML beans to simplify creation of primitive and aggregate
>> deployment descriptors. Once this is in place, I would also like to get
>> rid
>> of about 200 of static UIMA AE xml descriptors used to instantiate and
>> configure UIMA components. For this I would definitely use UimaFIT which
>> provides factories and API to dynamically create and configure AE
>> descriptors.
>> Let me know if you have any comments.
> In my opinion we should come up with a solution which allows specifying the
> configurationParameters directly inside the AE implemenation, maybe via
> Java Annotations or by API. Java Annotation could be combined with
> parameter
> injection, making the implementation of AEs shorter and more reliable.
> Anyway this would only make the xml descriptors shorter, the parameter
> values would still need to be configured. Or generated as proposed.
> Jörn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message