uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thilo Goetz <twgo...@gmx.de>
Subject Re: Tips for a beginner
Date Fri, 04 Dec 2009 08:10:12 GMT
Rogan Creswick wrote:
> On Thu, Dec 3, 2009 at 8:19 PM, Marshall Schor <msa@schor.com> wrote:
>> PEARs are both a packaging, and an "isolation" capability.
>> Packaging:  You get to zip up together potentially many components in an
>> aggregate, including the JARs, and the classpaths, so that others can
>> use the component.
>> Isolation: If your Pear uses a particular version of some Jars, included
>> in your PEAR package, UIMA runs these with an isolated class loader so
>> that your versions of the Jars are kept isolated from other versions of
>> the same Jars that might also be present in the rest of the system.
> Does anyone know how the Annotator Parameters / Resources play into
> PEAR packaging?
> I have a need for "configurable" PEARs: For example, machine learning
> algorithms that are self-contained in the PEAR, produce an agreed upon
> annotation, and can be parameterized with different knowledge bases.
> The goal is to reuse one PEAR to handle multiple data sets, or perform
> a similar test task with assorted sets of training data.  Since the
> implementation of the algorithm is separable from the training /
> knowledge base, it just makes sense to maintain that separation at the
> UIMA level too.
> I've managed to hack around the UIMA API for parameters (which don't
> seem to work for PEAR packaging) but the result is a bit fragile, and
> quite difficult to debug.  In particular, overridden parameters in
> aggregate annotators don't seem to "override" the component's
> parameter defaults at runtime -- as far as I can tell, this takes
> effect when the PEAR is packaged.
> Thanks!
> Rogan

This should be fixed in the current development version and the
(now really soon) upcoming release, see


>> This isolation may not be what you want, though. For more typical
>> component assembly, you put components together without Pear isolation,
>> using "plain" components and building normal aggregations of these.  In
>> this approach, you have to insure that any Jars used by the components
>> are at the same level.
>> When you're all done, you can deliver the resulting aggregate as a Pear,
>> if that is reasonable in your scenario, to others.
>> HTH.   -Marshall
>> William Colen wrote:
>>> Hello,
>>> We are moving our Brazilian Portuguese annotators (sentence detector,
>>> tokenizer, tagger, parser) to UIMA. We have different implementations of
>>> some annotators: some were created using OpenNLP, others where written from
>>> scratch.
>>> We would like to have .PEARs for each annotator, so in the applications we
>>> would change the annotators easily. Also we don't want to have duplicated
>>> resources (mostly dictionaries, and the UIMA typesystem descriptor), so we
>>> need a way to share.
>>> The first thing we did was to create the UIMA wrappers and descriptors. They
>>> are ready and we were able to create a UIMA application that uses the
>>> annotators (but we had to put all the code and descriptors in only one
>>> Eclipse project. No .pear yet).
>>> Now we are splitting the projects in smaller ones. For instance, we create
>>> only one TypeSystem.xml and would like every project to use it. So I created
>>> a simple .pear with the TypeSystem.xml.
>>> After that I created another pear for the sentence detector, but I couldn't
>>> import the TypeSystem.xml of the first pear. The only way to do that was
>>> using the relative path or if I put the TypeSystem.xml inside the JAR file
>>> of the first pear, and import it using classpath.
>>> Do you know a better way to do that?
>>> Latter I'll have to do the same with the dictionaries. I'm not sure if the
>>> best approach is to create a .pear only for it. Will it work?
>>> Thanks
>>> William

View raw message