oops, I see you already answered this. I failed to scroll the email to the
bottom and see that.
Sorry about that.
-Marshall
On 7/22/2011 4:50 PM, Marshall Schor wrote:
> 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
>>
