Re: OSGIing UIMA
On 1/28/2010 10:12, Tommaso Teofili wrote: > Hi all, > reading > http://cwiki.apache.org/UIMA/uima-osgi-enablement.html > I was wondering about how making uimaj available as an OSGI bundle. > I've seen the uimaj-as-osgi-runtime so I think I could make something > similar to it, and not using eclipse-plugin-supePom as parent, only for > uimaj-core, tools component-test, etc. (excluding AS stuff). > What do you think about it? > Since this is something I'm going to dig inside to integrate UIMA with > Clerezza do you have any suggestions/hints? > Cheers, > Tommaso > I've been thinking about this topic myself on and off for a while. I think it doesn't make much sense to create a UIMA core OSGi bundle without OSGi-enabling UIMA itself. If you go the OSGi route, you want your annotators to be bundles as well. So you need to add the ability to UIMA to load annotator OSGi bundles. I don't think that would be too hard to do, but I'm not sure it can be done in ways that are completely backward compatible. I would personally love to see OSGi bundles replace our pear format. Anyway, these are just my thoughts. If there is interest in really OSGiifying UIMA, that's something I'd be interested in contributing to. --Thilo
Re: OSGIing UIMA
Hi Thilo 2010/1/28 Thilo Goetz > I've been thinking about this topic myself on and off > for a while. I think it doesn't make much sense to > create a UIMA core OSGi bundle without OSGi-enabling > UIMA itself. If you go the OSGi route, you want your > annotators to be bundles as well. So you need to add > the ability to UIMA to load annotator OSGi bundles. I > don't think that would be too hard to do, but I'm not > sure it can be done in ways that are completely backward > compatible. I would personally love to see OSGi bundles > replace our pear format. > > Anyway, these are just my thoughts. If there is > interest in really OSGiifying UIMA, that's something > I'd be interested in contributing to. > > --Thilo > I agree with your points indeed, in my opinion making all UIMA components OSGI bundles would be a real plus in the means of standards, distribution, interoperabilty and more. On the contrary it might be not so good to have this change for deploying stuff in a non-OSGI environment so we should think about having alternative "packagings" for (backward) compatibility (for example using maven profiles, but it's just the first thing that comes to my mind). More over it could perhaps bring one more dependency (Felix?) inside UIMA so it would be another drawback. An alternative would be having a UIMA OSGIfier for each of the UIMA base components but I don't like the idea very much and it could be a long way ... Thanks Thilo, I am interested in this OSGIfication, what do others think about it? Cheers, Tommaso
Re: OSGIing UIMA
I'm probably showing my ignorance here :-) but, leaving aside the question of making core uima support annotators as osgi bundles, can you say what the differences are between the uimaj-ep-runtime bundle we build for eclipse, having all the core UIMA capability, and your goal below of "making uimaj available as an OSGI bundle"? My understanding is that Eclipse plugins are osgi bundles, and we build these using the Felix maven plugin, which wraps the standard OSGI bundle making code. Thanks for the clarifications... -Marshall Tommaso Teofili wrote: > Hi all, > reading > http://cwiki.apache.org/UIMA/uima-osgi-enablement.html > I was wondering about how making uimaj available as an OSGI bundle. > I've seen the uimaj-as-osgi-runtime so I think I could make something > similar to it, and not using eclipse-plugin-supePom as parent, only for > uimaj-core, tools component-test, etc. (excluding AS stuff). > What do you think about it? > Since this is something I'm going to dig inside to integrate UIMA with > Clerezza do you have any suggestions/hints? > Cheers, > Tommaso > >
Re: OSGIing UIMA
Tommaso Teofili wrote: > Hi Thilo > > 2010/1/28 Thilo Goetz > > >> I've been thinking about this topic myself on and off >> for a while. I think it doesn't make much sense to >> create a UIMA core OSGi bundle without OSGi-enabling >> UIMA itself. If you go the OSGi route, you want your >> annotators to be bundles as well. So you need to add >> the ability to UIMA to load annotator OSGi bundles. I >> don't think that would be too hard to do, but I'm not >> sure it can be done in ways that are completely backward >> compatible. I would personally love to see OSGi bundles >> replace our pear format. >> >> Anyway, these are just my thoughts. If there is >> interest in really OSGiifying UIMA, that's something >> I'd be interested in contributing to. >> >> --Thilo >> >> > > I agree with your points indeed, in my opinion making all UIMA components > OSGI bundles would be a real plus in the means of standards, distribution, > interoperabilty and more. On the contrary it might be not so good to have > this change for deploying > stuff in a non-OSGI environment so we should think about having alternative > "packagings" for (backward) compatibility (for example using maven profiles, > but it's just the first thing that comes to my mind). > More over it could perhaps bring one more dependency (Felix?) inside UIMA so > it would be another drawback. > We are already using Felix to build all of our Eclipse plugins, and other OSGi components. > An alternative would be having a UIMA OSGIfier for each of the UIMA base > components but I don't like the idea very much and it could be a long way > ... > Thanks Thilo, I am interested in this OSGIfication, what do others think > about it? > I'm somewhat interested, but don't really understand the motivations/goals, and the "proposal" in enough detail to have a better opinion. It would help me to have a wiki page describing this (any volunteers)? -Marshall > Cheers, > Tommaso > >
Re: OSGIing UIMA
Marshall Schor wrote: I'm probably showing my ignorance here :-) but, leaving aside the question of making core uima support annotators as osgi bundles, can you say what the differences are between the uimaj-ep-runtime bundle we build for eclipse, having all the core UIMA capability, and your goal below of "making uimaj available as an OSGI bundle"? My understanding is that Eclipse plugins are osgi bundles, and we build these using the Felix maven plugin, which wraps the standard OSGI bundle making code. Thanks for the clarifications... Isn't the only thing we are missing the support for annotators in OSGi bundles ? Right now that can be hacked by using the Eclipse-RegisterBuddy header, which works for example with the spring OSGi server. Thilo, why do you think we cannot add OSGi annotator bundles without breaking backward compatibility ? Beside that, it might be a bit more tricky for uima as because it relies on ActiveMQ which did not work well with OSGi in my tests with the uima as client and the spring OSGi server. Jörn
Re: OSGIing UIMA
Hi all, my initial need was to simply use UIMA as OSGI bundle so I looked at the uimaj-as-osgi-runtime and uimaj-eclipse-runtime that seem to me very near to what I deserve, they were fine except that (at the moment) I don't need the UIMA-AS packages and the 'eclipse' label puzzled me a bit and actually, as far as I can understand, the Eclipe plugin configurations in the uimaj-eclipse-plugins POM are not needed for an OSGI environment. So my first idea was only to do some crafting on uimaj-eclipse-runtime. What I realized after Thilo's reply was that instead of having a unique UIMA OSGI runtime artifact (bundle) with all the stuff inside we could make each UIMA module (uimaj-core, uimaj-tools, uimaj-cpe, etc) a single bundle with all its fine grain packages and resources. If this should be the case we should provide alternative packagings (jar/pear/bundle) to maintain compatibility with non-OSGI systems. More over (for annotators) if we enable the bundle packaging then we need to modify the tools that use pears i.e. the CVD to be able to load AEs also from a bundle. Thanks for your replies, Cheers. Tommaso 2010/1/28 Jörn Kottmann > Marshall Schor wrote: > >> I'm probably showing my ignorance here :-) but, leaving aside the >> question of making core uima support annotators as osgi bundles, can you >> say what the differences are between the uimaj-ep-runtime bundle we >> build for eclipse, having all the core UIMA capability, and your goal >> below of "making uimaj available as an OSGI bundle"? My understanding >> is that Eclipse plugins are osgi bundles, and we build these using the >> Felix maven plugin, which wraps the standard OSGI bundle making code. >> >> Thanks for the clarifications... >> >> >> > Isn't the only thing we are missing the support for > annotators in OSGi bundles ? Right now that can be > hacked by using the Eclipse-RegisterBuddy header, > which works for example with the spring OSGi server. > > Thilo, why do you think we cannot add OSGi annotator bundles > without breaking backward compatibility ? > > Beside that, it might be a bit more tricky for uima as because it > relies on ActiveMQ which did not work well with OSGi in my tests > with the uima as client and the spring OSGi server. > > Jörn >
Re: OSGIing UIMA
Tommaso Teofili wrote: Hi all, my initial need was to simply use UIMA as OSGI bundle so I looked at the uimaj-as-osgi-runtime and uimaj-eclipse-runtime that seem to me very near to what I deserve, they were fine except that (at the moment) I don't need the UIMA-AS packages and the 'eclipse' label puzzled me a bit and actually, as far as I can understand, the Eclipe plugin configurations in the uimaj-eclipse-plugins POM are not needed for an OSGI environment. So my first idea was only to do some crafting on uimaj-eclipse-runtime. When I created uimaj-as-osgi-runtime we named it osgi and not eclipse, because we noticed that it will now be used also outside of eclipse. We should rename uimaj-ep-runtime to uimaj-osgi-runtime. uimaj-ep-runtime does not depend on any eclipse plugins and can be used with an OSGi server. Actually I did that already together with Eclipse-RegisterBuddy to be able to load annotators from a bundle. What I realized after Thilo's reply was that instead of having a unique UIMA OSGI runtime artifact (bundle) with all the stuff inside we could make each UIMA module (uimaj-core, uimaj-tools, uimaj-cpe, etc) a single bundle with all its fine grain packages and resources. Taking this approach does not has a real advantage over the approach we have right now, in my opinion. Maybe you save a few KB storage on the server, if you do not deploy all the classes. But what else do you think we get ? If this should be the case we should provide alternative packagings (jar/pear/bundle) to maintain compatibility with non-OSGI systems. More over (for annotators) if we enable the bundle packaging then we need to modify the tools that use pears i.e. the CVD to be able to load AEs also from a bundle So annotator bundles are already supported. To make uima OSGi compliant we should do the annotator loading a bit different. Can we not use the OSGi's FrameworkUtil to load annotator class ? If so we can have a bundle activator for uima-ep-runtime which modifies the way annotators are loaded. Jörn
Re: OSGIing UIMA
On 1/28/2010 17:15, Jörn Kottmann wrote: > Marshall Schor wrote: >> I'm probably showing my ignorance here :-) but, leaving aside the >> question of making core uima support annotators as osgi bundles, can you >> say what the differences are between the uimaj-ep-runtime bundle we >> build for eclipse, having all the core UIMA capability, and your goal >> below of "making uimaj available as an OSGI bundle"? My understanding >> is that Eclipse plugins are osgi bundles, and we build these using the >> Felix maven plugin, which wraps the standard OSGI bundle making code. >> >> Thanks for the clarifications... >> >> > Isn't the only thing we are missing the support for > annotators in OSGi bundles ? Right now that can be > hacked by using the Eclipse-RegisterBuddy header, > which works for example with the spring OSGi server. > > Thilo, why do you think we cannot add OSGi annotator bundles > without breaking backward compatibility ? Good question. I should have written it down, I can't quite recall now what I was thinking of. One thing that might get interesting is JCas, and basically everything that does manual class loading. Maybe this can all be done in a backward compatible manner, though. Another thing that bears thinking about is our current OSGi/Eclipse bundles. They just export all packages that there are. If we change that and do not export packages that are really supposed to be implementation private, that would certainly break things. If we don't make that change, we loose at least some value of the OSGi-ification. --Thilo > > Beside that, it might be a bit more tricky for uima as because it > relies on ActiveMQ which did not work well with OSGi in my tests > with the uima as client and the spring OSGi server. > > Jörn
Re: OSGIing UIMA
Thilo Goetz wrote: On 1/28/2010 17:15, Jörn Kottmann wrote: Marshall Schor wrote: I'm probably showing my ignorance here :-) but, leaving aside the question of making core uima support annotators as osgi bundles, can you say what the differences are between the uimaj-ep-runtime bundle we build for eclipse, having all the core UIMA capability, and your goal below of "making uimaj available as an OSGI bundle"? My understanding is that Eclipse plugins are osgi bundles, and we build these using the Felix maven plugin, which wraps the standard OSGI bundle making code. Thanks for the clarifications... Isn't the only thing we are missing the support for annotators in OSGi bundles ? Right now that can be hacked by using the Eclipse-RegisterBuddy header, which works for example with the spring OSGi server. Thilo, why do you think we cannot add OSGi annotator bundles without breaking backward compatibility ? Good question. I should have written it down, I can't quite recall now what I was thinking of. One thing that might get interesting is JCas, and basically everything that does manual class loading. Maybe this can all be done in a backward compatible manner, though. What do you think about OSGi's FrameworkUtil, can we use that to do our class loading ? Jörn
Re: OSGIing UIMA
2010/1/29 Jörn Kottmann > Taking this approach does not has a real advantage over the > approach we have right now, in my opinion. Maybe you save a > few KB storage on the server, if you do not deploy all the classes. > But what else do you think we get ? > One thing that it would be useful is hot redeploying of only some of the components of the distribution (annotators or other modules) instead of the entire distribution. I personally like the idea of going towards something a bit more interoperable of our PEARs (that work pretty well indeed) but don't misunderstand me, I'm not for a "we must fully convert to OSGI now", let's put some ideas down and see if they are good. So I think Marshall's point of putting a wiki page to collect all the pros and cons is nice. Cheers, Tommaso
Re: OSGIing UIMA
On Fri, Jan 29, 2010 at 8:08 AM, Thilo Goetz wrote: > Good question. I should have written it down, I can't > quite recall now what I was thinking of. One thing that > might get interesting is JCas, and basically everything > that does manual class loading. Maybe this can all be > done in a backward compatible manner, though. There was an earlier effort at OSGI-fication of UIMA, see http://cwiki.apache.org/UIMA/uima-osgi-enablement.html As an observer, the biggest problem there were JCas classes combined with the UIMA design of dynamically constructing type systems at runtime. It seemed to me at the time that successful OSGI implementations would be possible only if type systems were elevated to first class objects supporting explicit dependencies, like annotators, and type definitions inside annotators were removed. Eddie