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) > >>>>> > >>> >
