Hello Roberto, > I did it. I've my version of analysisEngine:
that's an interesting approach, although its addresses only half of what I had in mind when I stated that components should be POJOs. The other half would be that the UIMA framework itself configures a component not via the initialize() method, but via Java-Bean getter/setters and possibly by checking if a component implements life-cycle interfaces, etc. If I understand your approach correctly, you suggest to ignore the UIMA assembly framework and operate directly on the level of AnalysisComponents. Did you make any provision to create aggregate analysis engines? The only method that I know to do that requires having the AnalysisEngineDescriptions of the aggregated engines. I think loosing the ability to use standard UIMA aggregates means loosing access to code that handles flow control (including CAS multipliers). > Now, with uimafit, it would be interesting to merge my feature with Fit. > Simply I don't have time :( uimaFIT tries not to be too Spring-specific. But since I like Spring and use it, I have already thought it might be a good idea to start implementing Spring-specific features in a separate uimaFIT-spring module. My feeling is, that I would prefer combining a SimpleNamedResourceManager-like approach with Spring instead of using your approach, meaning that named Spring beans would be exposed to UIMA via a custom ResourceManager. I believe this preserves more functionality from the UIMA framework - at least as long as the UIMA framework itself is does not configure components via getters/setters. A draw back of my approach is that UIMA components themselves are no Spring beans. I believe it works with PEARs - didn't try though. Do you see a problem if the Spring context is made accessible via the ResourceManager instead of making turning the components themselves into beans? What advantages do you see in the components themselves being beans? Cheers, Richard -- ------------------------------------------------------------------- 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 -------------------------------------------------------------------
