Hi, in my opinion, the best would be if UIMA components were just Java beans/POJOs.
UIMA comes compete with a framework for constructing workflows from XML descriptors. This is helpful in a scale-out scenario where UIMA needs to know all about how to instantiate all involved objects. UIMA provides little assistance for whom wants to code and run workflows directly from Java. This is one of the points where uimaFIT comes in, providing convenience "constructors" in the form of factory methods to facilitate this scenario. It would be nice if UIMA did use Java bean setters and @Resource annotations to configure components. Note though that uimaFIT allows to create a UIMA XML descriptor from a component class by extracting parameter names and default values. This is helpful to bridge between uimaFIT's annotation approach and existing UIMA tools. The descriptor generation would not be as easy in a POJO-like approach. It would also be nice if the distinction between the actual analysis components and the assembly framework would be clearer, so that components can be more easily used without the assembly framework in an embedded scenario or with an alternative POJO-based framework like Spring or Guice. uimaFIT explores who to bridge the current context injection using the initialize() method to a more modern annotation-based approach without changing UIMA itself. If the UIMA core would be changed to a more POJO-like implementation, uimaFIT might eventually become unnecessary. I could also imagine that uimaFIT might be merged into UIMA. However, I believe that at the moment uimaFIT benefits from being independent and having a faster release cycle. I think there is a lot to experiment with here and that uimaFIT could be an excellent playground and incubation project for dependency injection for UIMA. We use the Apache license to make the project attractive for all kinds of UIMA users. We also observe to use only Apache-licensed third-party libraries. -- Richard Am 21.03.2011 um 09:19 schrieb "Marshall Schor" <[email protected]>: > > > On 3/18/2011 4:09 PM, Alex Chaphiv wrote: >> Hi, >> >> I have several annotators that require objects that are rather complex to >> build. >> I've been able to get around this using by using ExternalResources with >> custom >> api interfaces, but it requires a lot of boilerplate and doesn't allow for >> sharing of dependencies between ExternalResources. > > Could you share what an "ideal" solution might look like, along with a small, > made-up sample of code that would use this ideal solution (with enough > comments > for wide understanding :-) )? > > Something that showed how the boilerplate is shrunk, and how dependencies are > specified? > > -Marshall Schor >> So what would be the best way to get around this? Even better, is there any >> support for Spring or Guice? >> >> >>
