ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Schmidt <>
Subject Re[4]: [SUBMIT] Input task to read input from during build run. Can exit build or create property from input.
Date Wed, 14 Nov 2001 18:58:15 GMT
Wednesday, November 14, 2001, 4:57:31 PM, you wrote:

>> I decided to overlap throwing a BuildException since exacly this
>> really was the missing bit for me.

> As throwing a BuildException is the missing bit in <available> for
> some people ... 

> I'm not really arguing against it at this point, just trying to make
> up my mind myself.

>> Also I'm not quite shure how to achieve this behaviour with a
>> combination of <fail>.  <condition> and <available> seem to set
>> properties instead of testing wheter a property matches a certain
>> value.

> See <equals> inside of <condition>

Will do so.

>> Otherwise I could imagine something like this:
>>   <input
>>     message="All data is going to be deleted from DB continue
>>     (y/n)?"  validargs="y,n" addproperty="build.abbort"
>>   />
>>   <condition"n">
>>                 <!-- ^ not implemented yet -->
>>     <fail> Build abborted by user.</fail>
>>   </condition>

> It would be more something involved like

> <target name="input">
>   <input ... />
>   <condition property="abort">
>     <equals arg1="${build.abbort}" arg2="y" />
>   </condition>
> </target>

I was trying to avoid a property for just exiting a build...

> <target name="fail-if-requested" depends="input" if="abort">
>   <fail ... />
> </target>

> which could be simplified by another long pending semi-rejected
> request for if/unless attributes on <fail>.

>> Also I see quite a difference between <fail> and <input>: <fail>
>> desinged for completely automated builds whereas <input> pauses and
>> requires some user interaction.

> Which doesn't mean that <input> also needs the ability to <fail> 8-)

>>> No userProperty, please.
>> Let me know and I'll take it out and post an update.

Will be removed.

> Fine, I think Christoph or whoever goes ahead and commits it (could be
> me as well), can take care of that, but submitting an altered version
> would probably be better.

> On another note - wouldn't it be better to add nested elements for
> validargs instead of a comma separated list?  What if people want to
> onclude a comma in a valid response?

Gave me something to think here... would apply to the <exitargs> as
well, of course ;-)

> Stefan


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message