You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2011/08/15 16:21:33 UTC
Testing of OSGi addon bundles
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)
Re: Testing of OSGi addon bundles
Posted by Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>.
If the bundle plugin (bnd) does not automatically generate the package versions, I believe it's possible to explicitly generate them explicitly. I came across then when I was trying to get my workspace set up recently.
http://fusesource.com/docs/esb/4.4/esb_deploy_osgi/BestPractices-BuildBundles.html
<Export-Package>
${project.artifactId}*;version=${project.version}
</Export-Package>
Cheers,
-- Richard
Am 16.08.2011 um 00:02 schrieb Marshall Schor:
> After spending a whole day on various experiments, I found that you can
> get the version="xxx" strings back if you back-level the version of the
> maven-bundle-plugin to 2.1.0 (it was at 2.3.4).
>
> I'll work on that and see if I can get by with using that older version.
>
> -Marshall
>
> On 8/15/2011 12:14 PM, Marshall Schor wrote:
>>
>> On 8/15/2011 11:42 AM, Marshall Schor wrote:
>>> A bit of investigation:
>>>
>>> OSGi says that since the unit of export is a package, the package should be
>>> "versioned", by adding and then maintaining packageinfo files. See
>>> http://www.aqute.biz/Bnd/Versioning
>>>
>>> However, these packageinfo files are
>> *not*
>>> used by our Eclipse plugins, which are also
>>> built using the maven-bundle-plugin, and they *have* the version information in
>>> the Export-Package, automatically provided (from somewhere, somehow).
>>>
>>> I tried a bunch of experiments to see if I could figure out where the bundle
>>> plugin was getting this, but couldn't find an answer. After searching google
>>> for this and not finding an answer, I've asked on the felix user's list :-) ...
>>>
>>> -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)
>>>>
Richard Eckart de Castilho
--
-------------------------------------------------------------------
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
eckartde@tk.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: Testing of OSGi addon bundles
Posted by Marshall Schor <ms...@schor.com>.
After spending a whole day on various experiments, I found that you can
get the version="xxx" strings back if you back-level the version of the
maven-bundle-plugin to 2.1.0 (it was at 2.3.4).
I'll work on that and see if I can get by with using that older version.
-Marshall
On 8/15/2011 12:14 PM, Marshall Schor wrote:
>
> On 8/15/2011 11:42 AM, Marshall Schor wrote:
>> A bit of investigation:
>>
>> OSGi says that since the unit of export is a package, the package should be
>> "versioned", by adding and then maintaining packageinfo files. See
>> http://www.aqute.biz/Bnd/Versioning
>>
>> However, these packageinfo files are
> *not*
>> used by our Eclipse plugins, which are also
>> built using the maven-bundle-plugin, and they *have* the version information in
>> the Export-Package, automatically provided (from somewhere, somehow).
>>
>> I tried a bunch of experiments to see if I could figure out where the bundle
>> plugin was getting this, but couldn't find an answer. After searching google
>> for this and not finding an answer, I've asked on the felix user's list :-) ...
>>
>> -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)
>>>
Re: Testing of OSGi addon bundles
Posted by Marshall Schor <ms...@schor.com>.
On 8/15/2011 11:42 AM, Marshall Schor wrote:
> A bit of investigation:
>
> OSGi says that since the unit of export is a package, the package should be
> "versioned", by adding and then maintaining packageinfo files. See
> http://www.aqute.biz/Bnd/Versioning
>
> However, these packageinfo files are
*not*
> used by our Eclipse plugins, which are also
> built using the maven-bundle-plugin, and they *have* the version information in
> the Export-Package, automatically provided (from somewhere, somehow).
>
> I tried a bunch of experiments to see if I could figure out where the bundle
> plugin was getting this, but couldn't find an answer. After searching google
> for this and not finding an answer, I've asked on the felix user's list :-) ...
>
> -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)
>>
Re: Testing of OSGi addon bundles
Posted by Marshall Schor <ms...@schor.com>.
A bit of investigation:
OSGi says that since the unit of export is a package, the package should be
"versioned", by adding and then maintaining packageinfo files. See
http://www.aqute.biz/Bnd/Versioning
However, these packageinfo files are used by our Eclipse plugins, which are also
built using the maven-bundle-plugin, and they *have* the version information in
the Export-Package, automatically provided (from somewhere, somehow).
I tried a bunch of experiments to see if I could figure out where the bundle
plugin was getting this, but couldn't find an answer. After searching google
for this and not finding an answer, I've asked on the felix user's list :-) ...
-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)
>
Re: Testing of OSGi addon bundles
Posted by Tommaso Teofili <to...@gmail.com>.
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 <ms...@schor.com>
> 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 <ms...@schor.com>
> >
> >> 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 <to...@gmail.com>
> >>>
> >>>> 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 <to...@gmail.com>
> >>>>
> >>>>> Thanks Marshall, will let you know how it goes.
> >>>>> Tommaso
> >>>>>
> >>>>>
> >>>>> 2011/8/16 Marshall Schor <ms...@schor.com>
> >>>>>
> >>>>>> 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)
> >>>>>>>
>
Re: Testing of OSGi addon bundles
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@schor.com>
>
>> 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 <to...@gmail.com>
>>>
>>>> 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 <to...@gmail.com>
>>>>
>>>>> Thanks Marshall, will let you know how it goes.
>>>>> Tommaso
>>>>>
>>>>>
>>>>> 2011/8/16 Marshall Schor <ms...@schor.com>
>>>>>
>>>>>> 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)
>>>>>>>
Re: Testing of OSGi addon bundles
Posted by Tommaso Teofili <to...@gmail.com>.
2011/8/20 Marshall Schor <ms...@schor.com>
> 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 <to...@gmail.com>
> >
> >> 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 <to...@gmail.com>
> >>
> >>> Thanks Marshall, will let you know how it goes.
> >>> Tommaso
> >>>
> >>>
> >>> 2011/8/16 Marshall Schor <ms...@schor.com>
> >>>
> >>>> 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)
> >>>>>
> >>>
>
Re: Testing of OSGi addon bundles
Posted by Marshall Schor <ms...@schor.com>.
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 <to...@gmail.com>
>
>> 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 <to...@gmail.com>
>>
>>> Thanks Marshall, will let you know how it goes.
>>> Tommaso
>>>
>>>
>>> 2011/8/16 Marshall Schor <ms...@schor.com>
>>>
>>>> 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)
>>>>>
>>>
Re: Testing of OSGi addon bundles
Posted by Tommaso Teofili <to...@gmail.com>.
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 <to...@gmail.com>
> 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 <to...@gmail.com>
>
>> Thanks Marshall, will let you know how it goes.
>> Tommaso
>>
>>
>> 2011/8/16 Marshall Schor <ms...@schor.com>
>>
>>> 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)
>>> >
>>>
>>
>>
>
Re: Testing of OSGi addon bundles
Posted by Tommaso Teofili <to...@gmail.com>.
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 <to...@gmail.com>
> Thanks Marshall, will let you know how it goes.
> Tommaso
>
>
> 2011/8/16 Marshall Schor <ms...@schor.com>
>
>> 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)
>> >
>>
>
>
Re: Testing of OSGi addon bundles
Posted by Tommaso Teofili <to...@gmail.com>.
Thanks Marshall, will let you know how it goes.
Tommaso
2011/8/16 Marshall Schor <ms...@schor.com>
> 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)
> >
>
Re: Testing of OSGi addon bundles
Posted by Marshall Schor <ms...@schor.com>.
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)
>