Hello Matt.
Many thanks for that. I believe this suits my intent perfectly!

Regards,
Parag Doke
Save paper, save trees. Do not print emails/documents unless
absolutely necessary.



On Sun, Mar 13, 2011 at 1:08 PM, Matt Benson <gudnabr...@gmail.com> wrote:
> You should see the <local> task, whereby you can set up scoped
> property "shadowing."
>
> Matt
>
> On Sat, Mar 12, 2011 at 10:59 PM, Parag Doke
> <parag.doke+tec...@gmail.com> wrote:
>> Any ideas anyone ?
>> Thanks in advance,
>> Parag Doke
>> Save paper, save trees. Do not print emails/documents unless
>> absolutely necessary.
>>
>>
>>
>> On Mon, Mar 7, 2011 at 12:52 PM, Parag Doke <parag.doke+tec...@gmail.com> 
>> wrote:
>>> Hello ant users.
>>> I am facing an issue with handling properties with calls to tasks/macros
>>> nested within the parallel task. More of a logical/approach related issue
>>> rather than anything with the tool itself. Here go the details:
>>> Using ant:
>>> Apache Ant version 1.8.1 compiled on April 30 2010
>>> With Java:
>>> java version "1.6.0_22"
>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>> Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)
>>> The most relevant part of the build.xml:
>>>         <parallel>
>>>             <mySleep seconds="4"/>
>>>             <mySleep seconds="3"/>
>>>             <mySleep seconds="2"/>
>>>             <mySleep seconds="1"/>
>>>         </parallel>
>>> mySleep is my own macro with the following declaration:
>>>     <macrodef name="mySleep">
>>>         <attribute name="seconds"/>
>>>         <sequential>
>>>             <sleep seconds="@{seconds}"/> <!-- In my actual case, this is
>>> exec calls with the outputproperty attribute -->
>>>             <property name="myProp" value="my value = @{seconds}"/>
>>>             <echo>Now working with ${myProp}</echo>
>>>         </sequential>
>>>     </macrodef>
>>> Since properties are immutable, if it so happens that the 4th macro call
>>> sets the property, the rest of them cannot modify it. A quick alternative to
>>> this might be using the variable task (in place of property) from
>>> ant-contrib.sf.net. However, the above is just an example. In reality, my
>>> macro does an exec call. The outputproperty attribute to the exec call will
>>> be what I need to process later.
>>> So I guess my questions are:
>>> 1) What is the best approach to handle properties/variables for (almost)
>>> identical macro calls ? I cannot modify the property name each time. I could
>>> redirect stdout/stderr of the exec task to some file. But not sure how to
>>> guarantee that the file will be unique and not get overwritten if 2 tasks
>>> finish at the same instant of time.
>>> 2) Can the outputproperty value be captured in a variable directly ? I read
>>> that it is possible to use the ant-contrib propertycopy task to get one
>>> property value into another. But then there is a risk that the copy might
>>> not be synchronized ...
>>> The last option I have is of course to get rid of the parallel task and let
>>> the macros run one after the other. But that would be modifying the
>>> requirement to suit the scripting limitation I've run into. So I thought of
>>> asking here before jumping on any implementation.
>>> Thanks in advance for any pointers,
>>> Parag Doke
>>> Save paper, save trees. Do not print emails/documents unless absolutely
>>> necessary.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
>> For additional commands, e-mail: user-h...@ant.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org

Reply via email to