Re: Delayed properties resolving

Hello Dan,

I understand what you want now. If you define cmnd.opts inside proj1.xml 
and proj2.xml instead of in the top most config.xml,
you should be fine. It is true that it is a repetition.

A way to avoid this repetition would be to use an entity include, or to 
define projects which are similar using a plugin definition.

see http://confluence.public.thoughtworks.org/display/CC/ConfigFiles

Regards,

Antoine

Dan Tihelka wrote:
>> I am not sure what is the problem with the current behavior of
>> CruiseControl. Do you want to change property values during builds ?
>>
>> Or do you have some key/values pairs defined in external property files
>> which you change externally ?
>>     
>
> Not exactly. The setting is "fixed" in project XML files, but imagine the 
> following situation:
>
> <!-- TOM-MOST projects definition file -->
> <cruisecontrol>
>
>   <!-- default property values, shared by more projects -->
>   <property name="prop1"  value="val1_default"/>
>   <property name="prop2"  value="val2_default"/>
>   <property name="prop3"  value="val3_default"/>
>   <property name="prop4"  value="val4_default"/>
>
>   <!-- defines default command behaviour:
>        binary -a val1_default -b val2_default -c val3_default -d val4_default
>   -->
>   <property name="cmnd.opts"  value="-a ${prop1} -b ${prop4} -c ${prop3} -d 
> ${prop4}"/>
>
>   <include.projects file="proj1.xml" />
>   <include.projects file="proj2.xml" />
>
> </cruisecontrol>
>
>
>
> <!-- proj1.xml -->
> <cruisecontrol>
>
>   <!-- needs to redefine some properties
>   <property name="prop2"  value="val2_new"/>
>
>   <!-- require to execute command:
>         binary -a val1_default -b val2_new -c val3_default -d val4_default
>
>         but executes the default command:
>         binary -a val1_default -b val2_default -c val3_default -d val4_default
>   -->
>    <schedule>
>         <exec  command="binary" args="${cmnd.opts}" />
>    </schedule>
>
> </cruisecontrol>
>
>
>
> <!-- proj2.xml -->
> <cruisecontrol>
>
>   <!-- needs to redefine some properties
>   <property name="prop1"  value="val1_new"/>
>   <property name="prop4"  value="val4_new"/>
>
>   <!-- require to execute command:
>         binary -a val1_new -b val2_default -c val3_default -d val4_new
>
>         but executes the default command:
>         binary -a val1_default -b val2_default -c val3_default -d val4_default
>   -->
>    <schedule>
>         <exec  command="binary" args="${cmnd.opts}" />
>    </schedule>
>
> </cruisecontrol>
>
>
> Is it more clear?
> Kind regards,
> Dan T.
>
>   
>> I have hacked CruiseControl to read properties from LDAP, giving the
>> possibility to create one property per attribute found in a LDAP
>> directory context.
>>
>> I am using this mechanism to define branch specific parameters, for
>> instance the name of the UT WebSphere Server and the name of the
>> Selenium WebSphere server.
>>
>> I did not submit this change in JIRA yet but would be interested to.
>> Since this one is using only JNDI it does not require external libraries.
>>
>> Regards,
>>
>> Antoine
>>
>> Daniel Tihelka wrote:
>>     
>>> Dear CruiseControl users and developers.
>>>
>>> No idea or just not interesting feature? I want have to know ...
>>>
>>> If you are interested, just write me few notes of your opinion about the
>>> best way of implementing it, or where I should start to examine
>>> possibilities, and I will try to implement it (to Dan Rollo: taking care
>>> for all the tests this time ;-) ).
>>>
>>> Should I open new JIRA issue?
>>>
>>> Thank you very much,
>>> Dan T.
>>>
>>>       
>>>> So, what to do with it?
>>>>
>>>> - there already is a way of achieving it. Please, if you know the way,
>>>> let me
>>>>         
>>> know ...
>>>
>>>       
>>>> - change the behavior of CC to resolve the properties at the last
>>>> moment,
>>>>         
>>> just before they are used. However, it may change the behavior of CC, and
>>> someone may rely on it. Therefore, I expect it is hardly acceptable
>>>
>>>       
>>>> - add new optional attribute to <property /> tag, something like
>>>>         
>>> "delayresolving=true", with default to "false" if not set; that would
>>> cause the resolving of properties to the last moment before they are
>>> required; the original behavior will stay unaffected
>>>
>>>       
>>>> - ??? any better/cool idea?
>>>>         
>
>   


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev