On 1/9/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Mirko has posted a long comment about UIMA and OSGi on our Wiki: http://cwiki.apache.org/confluence/display/UIMA/UIMA+OSGi+Enablement Mirko, what particularly intrigued me were your comments about OSGi and how it conflicts with JCas. I had actually hoped that OSGi would help us solve some of our JCas problems.
OSGi enablement, actually, can help resolving some of the JCas problems, but to get really significant improvements we should consider re-designing the JCas mechanism to make it fit the OSGi environment. The proposed OSGi Service Adaptor solution, which will be presented in details on the wiki site in the nearest future, helps packaging and distributing JCas TS classes (as OSGi fragment bundles), as well as dynamically installing JCas TS classes and extending the global TS class space without restarting the whole application. This solution does not resolve all the JCas problems, but it establishes the basis for resolving these problems in the future. [...]
You can see where this is going. I had hoped that with the OSGi component model and class space support, we would find a way to keep the JCas user friendly (by allowing JCas generation at the component level), while still making it work in larger deployments. However, I have not conducted any UIMA OSGi experiments myself, so this is just a theoretical notion ;-) Please let us know what you think. The JCas is one of my motivations for being interested in OSGi. I hope you won't dash my hopes completely. --Thilo
The basic motivation behind OSGi enablement in UIMA is providing UIMA developers with the standard way of packaging, managing and deploying UIMA components. Our current solution - OSGi Service Adaptor - is based on several design considerations and requirements of the UIMA community. One of the big problems in OSGi enabled UIMA is handling JCas TS classes, and we are going to post a presentation on this topic on the wiki site soon. What we propose regarding the handling of JCas TS classes is just the first step in making this mechanism OSGi compatible. -- Lev
