Thanks, Tommaso, for your careful testing of various OSGi packaging alternatives :-).
For your additional use case # 1 below -- where we need to have "exported" the packages for the application API to UIMA -- we could add those exports. But this might break the following use case: you have 2 annotators packaged this way A and B. The OSGi wiring will pick up one of these (say A) to use for the UIMA framework packages. When the produceAnalysisEngine is called in B, it will use A's UIMA framework classes, and when these now try and do classloading, they will fail because they can't "see" B's classes. Alternatives here might include going against typical OSGi practices by *not* importing the packages you export. In this case, each package would have its own copy of the UIMA framework classes. -- Maybe this is the best temporary solution? ====================== For use case #2 (where we try to have the UIMA Framework itself as a separate, sharable bundle) - some ways I see to get this to work in OSGi are to use things like Eclipse Buddy with an OSGi framework which supports this (which Felix does not), or to mark all the Annotator Packages as being fragments of the common UIMA Framework. (There may be another solution involving Dynamic-imports?) I'm not sure of the downsides of doing fragments, other than reducing the modularity of the annotator bundle fragments, since they now would all be loaded under the host (UIMA framework) class-loaders AFAIK. And there's another way - changing the UIMA Framework itself to support OSGi-style class loading :-). This might involve "detecting" the OSGi environment, and then using OSGi services to locate, install, and load the annotator bundle classes. ====================== I do think this will take some time to sort out, and I want to get our addons package released :-). So I think in any case we have a situation where the OSGi packaging of annotators is "experimental" and subject to changing. It seems not too useful in its current packaging, though. If we don't include the OSGi stuff in the release, we could "include" it in the SVN checkout & build from sources, in the sense that individuals could build OSGi packagings from source, using our Maven build processes. So, here are some alternatives: 1) include the OSGi packagings (call them experimental) in the release a) as is b) with adding exports without imports of the UIMA framework classes 2) drop the OSGi packagings from the release, but provide a simple way to build them from source-release or SVN checkout. Given that more experimenting probably needs to be done to figure out what would be useful OSGi packagings, I'm leaning toward 2), although maybe 1b) is sufficiently "useful" to warrant releasing. ====================== What do others think? -Marshall On 8/19/2011 5:58 PM, Tommaso Teofili wrote: > Hello all, > After some hours spent on this OSGi testing I can say the base use case, as > explained by Marshall at [1], where OSGi packaging of an annotator is run > standalone in Felix is ok. > Other use cases where the current configuration is not working are: > 1) a bundleX is defining one of the (OSGi) annotators as dependency and > trying to create an AnalysisEngine (i.e.: > UIMAFramework.produceAnalysisEngine(desc); ) as org.apache.uima.* is not > exported. > 2) a bundleX is defining both uimaj-ep-runtime and one of the (OSGi) > annotators as dependencies and trying to create an AnalysisEngine. > I am now testing other possibilities like wrapping everything needed to run > a custom UIMA pipeline in one 'big' bundle but I'm pretty sure this will > work. > I am also inspecting using the ResourceManager extensionClassPath (no change > to code) or one typical OSGi 'alternative' for Class.forName method > (Thread.currentThread().getContextClassLoader(), requires change in > PrimitiveAnalysisEngine_Impl at least) but I am still experimenting. > At this point I think we have 3 options: > 1 - release things as they are now in addons and improve them along time > 2 - don't release the OSGi packaging until there is a better/full support > for OSGi in UIMA > 3 - put back the OSGi stuff in the sandbox and make a separate release > marked as alpha or something similar > I'd be happiest with 1, quite happy with 3 and not so happy with 2 but I'd > like to hear what do others think. > Regards, > Tommaso > > [1] : http://uima.apache.org/staging/osgi.html > > > > 2011/8/17 Tommaso Teofili <[email protected]> > >> After re doing the tests within Felix with the updated trunk I confirm the >> issue with versions was solved :) >> I am doing some more tests now to check the current configuration makes it >> possible to run the annotators flawlessly (this is especially important for >> possible classloading issues). >> I'll detail which configurations are proved to work (i.e.: bundleA using >> annotatorX and bundleB using bundleA) and which are not (if any). >> Tommaso >> >> >> >> 2011/8/16 Tommaso Teofili <[email protected]> >> >>> Thanks Marshall, will let you know how it goes. >>> Tommaso >>> >>> >>> 2011/8/16 Marshall Schor <[email protected]> >>> >>>> The OSGi build has been redone with an approximation to the version >>>> information. >>>> >>>> The maven-bundle-plugin version was reset back to 2.1.0, which adds a >>>> version >>>> number for all packages in the export list. This approach is not in line >>>> with >>>> the OSGi model, which wants each "package" to have its own version, but >>>> it is >>>> probably enough to get going. >>>> >>>> Tommaso, it would be good if you could update from trunk and rebuild the >>>> OSGi >>>> plugins and retest. >>>> >>>> -Marshall >>>> >>>> On 8/15/2011 10:21 AM, Marshall Schor wrote: >>>>> Tommaso has done some testing, and found that the MANIFEST files don't >>>> contain >>>>> the versions exported so that other bundles (the ones 'using' the >>>> annotators) >>>>> which declare to import packages of a certain version cannot be started >>>>> correctly even if the annotator bundle was correctly started: >>>>> ... >>>>> [ 128] [Active ] [ 5] UIMA Annotator: AlchemyAPIAnnotator >>>> (2.3.1.SNAPSHOT) >>>>> [ 129] [Active ] [ 5] UIMA Annotator: OpenCalaisAnnotator >>>> (2.3.1.SNAPSHOT) >>>>> [ 131] [Active ] [ 5] Clerezza - Apache UIMA related ontologies >>>>> (0.1.0.incubating-SNAPSHOT) >>>>> [ 132] [Active ] [ 5] UIMA Eclipse: uimaj-ep-runtime (2.3.1) >>>>> ... >>>>> start >>>> file:/Users/tommaso/Documents/uima.utils-0.1-incubating-SNAPSHOT.jar >>>>> org.osgi.framework.BundleException: Unresolved constraint in bundle >>>>> org.apache.clerezza.uima.utils [135]: Unable to resolve 135.0: missing >>>>> requirement [135.0] package; >>>>> (&(package=org.apache.uima.alchemy.ts.categorization)(version>=2.3.0)) >>>>> >>>>> If I run 'inspect package capability <bundleid>' for >>>> OpenCalaisAnnotator I get: >>>>> inspect package capability 129 >>>>> org.apache.uima.OpenCalaisAnnotator [129] exports packages: >>>>> ----------------------------------------------------------- >>>>> org.apache.uima.annotator.calais; version=0.0.0 >>>>> org.apache.uima.calais; version=0.0.0 >>>>> >>>>> -Marshall (copying part of note from Tommaso) >>>>> >>>
