On 28.11.2013, at 07:45, Jens Grivolla <[email protected]> wrote:
> Hi, basically I'm looking for a way to manage engine descriptions. So far I'm
> using createEngineDescription(...) when building a pipeline. If my
> component, i.e. in the case of uimaFIT the class that implements the AE,
> defines good default values that is very easy and concise.
>
> However, I also have many cases where I have different
> descriptors/descriptions that use the same class, and sometimes I then again
> override some parameters. I would like to manage those descriptions
> separately from the pipeline where they are used, e.g. with Maven. I want to
> avoid copy and pasting common parameter configurations from one pipeline to
> the other.
>
> So far I was using different XML descriptors, each packaged in a separate
> PEAR as an independent component, and would build my pipeline based on those.
> With uimaFIT I haven't found a good way to do this.
>
> Basically I would like to have inheritance at the description level. This
> could either be through Java inheritance (i.e. CountryMapper.class extends
> ConceptMapper.class and overrides default parameter values) or through a way
> to store EngineDescriptions and reuse them, without having to resort to XML
> files.
Well, AnalysisEngineDescriptions are "just" in-memory representations of the
XML files (or vice versa if you prefer). You can save a descriptor that you
created with uimaFIT as XML. Later, you can load the descriptor again with
uimaFIT and override additional parameters. (see below)
> So I would in some place define "countryMapper =
> createEngineDescription(ConceptMapper.class, <parameters>)" and package that
> as a Maven artifact, and somewhere else use it to build a pipeline using
> createEngineDescription(countryMapper, <additional_parameters>).
So three steps: 1) create base descriptor 2) package base descriptor 3) create
derived descriptor
1) create base descriptor
desc = createEngineDescriptor(ConceptMapper.class, <parameters>);
desc.toXml(…)
2) package base descriptor
Package resulting descriptor in a JAR X, e.g. as
/my/package/CustomConceptMapper.xml
There is no convenient support of doing this automatically as part of a build
right now. It should be possible with Maven though to first build some factory
class which creates this descriptor and then later in the build call this class
to have it created as part of the build. We did similar things in uimaFIT for
auto-generating types in 1.4.x. It could look somewhat like this:
in 1) do desc.toXml(new
FileOutputStream("target/classes/my/package/CustomConceptMapper.xml")
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<mainClass>my.package.DescriptorGenerator</mainClass>
</configuration>
</plugin>
3) create derived descriptor
Add JAR X as a dependency to your project.
desc = createEngineDescriptor("my.package.CustomConceptMapper",
<parameterOverrides>)
> My problem is that I don't think I can override the default values with Java
> inheritance, and don't have a good way to package EngineDescriptions. I
> guess I could have a class with a static method that returns the engine
> description and package that, but it would be nice to have something more
> "standard" and elegant.
There is an issue for overriding parameter values, but it has not been moved to
the Apache Jira yet:
https://code.google.com/p/uimafit/issues/detail?id=69
I've been thinking about adding a new class-level annotation @OverrideParameter
to do something like this:
@OverrideParameter(
@ConfigurationParameter(name= ConceptMapper.PARAM_XXX, defaultValue="YYY"))
class CustomConceptMapper extends ConceptMapper { … }
I'd probably only use that carefully to manage descriptors as you plan to. When
I was looking for such a functionality, I rather had a case with an abstract
base class which I wanted to define a parameter without any default value, and
then I wanted to override the parameter in a sub-class.
@OverrideParameter(
@ConfigurationParameter(name= AbstractReaderBase.PARAM_FILES,
defaultValue="*.txt")
class TextReader extends AbstractReaderBase { … }
The reason I think these are two different cases is, that my case is pretty
much restricted to declaring parameters as part of a generic interface
(realized in the abstract class), and then add default values for them in
sub-classes. You appear to aim at a more general and flexible mechanism for
composing descriptors, which may or may not be related to Java inheritance.
-- Richard
> Thanks,
> Jens
>
> On 11/28/2013 12:37 AM, Richard Eckart de Castilho wrote:
>> Hi,
>>
>> I'm not sure that I understand what you want to do. When you create a
>> descriptor for a component e.g. using createEngineDescription(…), this
>> descriptor is configured with the default values (unless you override them
>> in the call to createEngineDescription).
>>
>> You can change parameters on such a descriptor using
>> ResourceCreationSpecifierFactory.setConfigurationParameters(…)
>>
>> Does that help? Can you make a more vivid example of what you are trying to
>> accomplish, maybe with a bit if pseudo-code marking those places that
>> remain unclear how to handle them?
>>
>> Cheers,
>>
>> -- Richard
>>
>> On 27.11.2013, at 07:47, Jens Grivolla <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> so far we were using PEARs to manage different configurations of
>>> components, e.g. having a CountryMapper, CityMapper, PersonMapper, etc.,
>>> all based on ConceptMapper but with different settings/models.
>>>
>>> How would I do that in uimaFIT? Basically I would like to create components
>>> that just override the default values for parameters/resources.
>>>
>>> In some cases, parameters are additionally overridden at the pipeline level
>>> (CPE/uimaFIT), e.g. when using a database CasConsumer where we would have
>>> several base configurations (e.g. annotation to DB column mappings), but
>>> then override the DB connection settings in the pipeline.
>>>
>>> Having the full configuration at the pipeline level makes it much more
>>> difficult to manage configurations, so I would like to be able to point to
>>> a given component and automatically get the correct default settings.
>>>
>>> Thanks,
>>> Jens
