Am 20.07.2011 um 20:38 schrieb Marshall Schor: > I can think of 2 scenarios (maybe because I have a limited imagination :-) ): > > 1) UIMA is augmented to incorporate within itself whatever is needed to run > OSGi > - packaged annotators (and perhaps, separately OSGi-packaged type systems and > shared resources). In this case, UIMA itself becomes yet another OSGi > "container".
I think UIMA should not embed OSGi, which again would mean that it mandates the use of OSGi. But UIMA should be usable in OSGi scenarios. EclipseLink does not use OSGi as a plugin-system, but it allows e.g. plugin in classloaders which makes it more convenient to use within an OSGi runtime environment. If you say "OSGi container", I think of something like Equinox or Felix. I am certain we do not want to implement another OSGi container. > 2) The UIMA Framework is made into one or more OSGi components, in such a > manner > as to enable some very simple "driver" application to take the UIMA framework > and one or more OSGi-packaged parts, as above, and run them in some 3rd party > OSGi container (like Felix). That seems to me the reasonable scenario. However, it should be done in such a manner that the UIMA framework is still usable outside an OSGi container. That means the JARs can contain bundle metadata, but the framework itself should not have dependencies on any OSGi library. It would make sense to provide an OSGi support package for UIMA which then contains OSGI-specific code, such as an extension point registry, factories, etc. That should be a layer between the UIMA core framework and an OSGi-based application such as the CAS Editor, Eclipse etc. > Here's a variation on the above: allow somehow combining other packaging of > annotators (e.g., "normal", and "PEAR") together with OSGi - packaged ones. I don't like pears very much because they need to be installed and don't "just run" from the classpath. I can't just add a PEAR as a dependency to my Maven project and use the component. With OSGi packaged components, just dropping them in to the OSGi container should "just work" - no need to install them. Maybe it would be possible to add OSGi metadata to PEARs so they could operate in both environments - the OSGi metadata might just be able to provide the OSGi container with the right information to do that. Unfortunately, a PEAR would (correct me I am wrong) never be usable when just added to the classpath via a Maven dependency. > Are you thinking of all these variations, or does only one of them make sense? I think only the second variation makes sense. -- 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] (0)6151 16-7477, fax -5455, room S2/02/B117 eckar...@tk.informatik.tu-darmstadt.de www.ukp.tu-darmstadt.de Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de -------------------------------------------------------------------
