Re: 1b) alternative. After some more thought, I don't think 1b) will quite do what I thought it would. Consider a bundle C wanting to use bundle A containing the UIMA framework (exported from A) and the annotator in bundle A. Bundle C would get "wired" to the UIMA framework classes to produce Analysis Engines in bundle A, and call these classes, which would successfully instantiate / run annotator A.
So far so good. Now consider bundle B - another annotator, plus the Exported UIMA framework. If Bundle C wants to also be wired to bundle B, because it wants to also run annotator B, the OSGi framework would have to pick just one of bundle A or bundle B to provide the classes for the UIMA framework. If it picked bundle A, then it would call produceAnalysisEngine using classes from bundle A, which would not be able to see the classes for bundle B. So this would not work, I think. We could do 1b) but with the understanding that it would only permit one bundle containing the UIMA framework classes to work. With that limitation, is that still something of interest? -Marshall On 8/21/2011 8:17 AM, Tommaso Teofili wrote: > 2011/8/20 Marshall Schor <[email protected]> > >> 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. >> > correct > > >> 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 was studying this option of fragments and dynamic imports but I think this > would require more time now, so I'd do this past the release. > > >> 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. >> > yes, this would be the best option in my opinion, but requires a stronger > effort (and consensus) by the whole community I think. > > >> ====================== >> >> 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? >> > I vote for 1b. > Tommaso > > >> -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) >>>>>>>
