Hi Marshall--
| 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.
Hmm. I had never imagined UIMA OSGI bundles as stand-alone deployables
(i.e. without any additional UIMA libraries). I'd always imagined them as
a packaging for annotators and analysis engines that can be plugged into a
UIMA container (like CPM, for example). In the same way that Eclipse
extensions plug into Eclipse. They would only contain their own
implementation classes. In other words, a replacement for PEAR files.
I suppose that deploying the UIMA container itself as an OSGi bundle would
be nice too, but not as important as the annotators and analysis engines.
Those represent the level of re-usability and modularity that I really
want.
From this page [1], it seems like IBMers Yurdaer Doganata and Mirko Jahn
solved this problem back in 2007.
As fellow employees, is anyone here in touch with them? Can we get them
to donate their code to Apache? Better than re-inventing the wheel, right?
Greg
[1] https://cwiki.apache.org/UIMA/uima-osgi-enablement.html
