What are the arguments/reasons to prefer the ${xxx} style?
One I can think of is that it makes it explicit in the descriptor what value is
being potentially overridden by a top level properties file. Unless the
descriptor was altered to include this, it would prevent a top level properties
file from overriding.
Are there other reasons to prefer this style over the other one?
-Marshall
On 7/22/2011 2:44 PM, Adam Lally wrote:
> On Fri, Jul 22, 2011 at 2:09 PM, Marshall Schor <[email protected]> wrote:
>
>> The proposal to add ${xxxx} kinds of things into descriptors is one way to
>> specify the parameter being overridden.
>>
>> Another way is to have the properties file, itself, contain a direct
>> specification of the parameter being overridden, perhaps using the same
>> syntax
>> we already use:
>>
>> keyname1/keyname2/.../keynamen/propertyName = value
>>
>> where the keyname1 ... n are the key names of the delegates in the
>> aggregates.
>>
>> There are pluses and minuses for both approaches. Here are some:
>>
>> The same annotator component, using the same XML descriptor, might be
>> included
>> in two different places in a big aggregate. With the ${xxx} approach, the
>> override would affect both, and it would not be possible to have different
>> overrides for each one (unless of course, you changed that component's
>> descriptor to, for example, use ${xxx} in one instance, and ${yyy} in the
>> other).
>>
> It would still be possible to use the existing UIMA parameter override
> mechanism in this case. In the aggregate that imports these descriptors, we
> can introduce an overriding parameter and sets its value to ${xxx} in one
> case and ${yyy} in another.
>
>
>> Using the keyname1/keyname2/... approach makes it pretty explicit, in one
>> spot,
>> what is being overridden. The ${xxx} approach creates a bit of an
>> indirection -
>> it would be necessary to grep through all the xml files, whereever they may
>> be
>> located, to see what was being overridden.
>>
>>
> In my use case I have a requirement (which I should have mentioned, sorry)
> that I want to be able to have a single properties file that I can use with
> multiple different aggregates.
>
> Consider the case where I have one top level aggregate, AE1, that contains
> two components, AE2 and AE3, themselves aggregates. Right now AE1 has all
> my parameter settings, via parameter overrides. But sometimes, I want to
> separately run AE2 or AE3 (for debugging, or for service deployment). In
> order to do that now I have to manually make sure all the parameter
> overrides that I set in AE1 are set separately in AE2 and AE3, which makes
> things very difficult to maintain.
>
> So, I thinking I could have one place where I keep all my settings (like a
> properties file, though the exact format is not too important), and I could
> use that same file whether I run AE1, AE2, or AE3. If the configuration
> file has to specify the exact path down from the top of the aggregate, this
> would not be possible.
>
> -Adam
>
