Right Marshall, this is also my understanding. At this stage, it seems to me a reasonable compromise if we mark the OSGi support for annotators as an experimental feature, with this particular limitation documented. Tommaso
2011/8/21 Marshall Schor <[email protected]> > 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) > >>>>>>> >
