ant-dev mailing list archives

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

> Tuesday, November 13, 2001, 1:43:16 PM, you wrote:
>> As there always seems to be something that is getting a higher
>> priority, we may as well include this task to at least have
>> something to get us started.
> Would appreciate to further participate with this.

You're welcome.

> 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>

> 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" />

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

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> is
> 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.

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?


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

View raw message