ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Schmidt <>
Subject 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 11:09:17 GMT
Hello Stefan,

Tuesday, November 13, 2001, 1:43:16 PM, you wrote:

> On Sat, 10 Nov 2001, Ulrich Schmidt <> wrote:

>> Input task allows user interaction during the build process by
>> displaying a message and reading a line of input from the
>> console (

> Well, a long long time ago we wanted to abstract the input system out
> into a system taht allows a GUI frontend to live on top of Ant, a
> browser frontend a ...

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

>> Optionally a set of exit arguments can be defined via the exitargs
>> attribute.

> This is where it overlaps with <fail>, I'm not sure how we want to
> deal with it.  We had a similar discussion with <available> - in some
> situation it may be better to have a fail attribute on <available>
> then to use a marker property.  Back then we decided against the fail
> attribute of <available>.

I decided to overlap throwing a BuildException since exacly this
really was the missing bit for me. 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. Otherwise I could
imagine something like this:

    message="All data is going to be deleted from DB continue (y/n)?"
                <!-- ^ not implemented yet -->
    <fail> Build abborted by user.</fail>

instead of:

    message="All data is going to be deleted from DB continue (y/n)?"
    exitmessage="Build abborted by user."

One issue with the above would be that you can not reset a property.
So the user will be forced to invent quite a few property names if
the task occures multiple time. This seems to be quite error prone
to me.

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.

>> Optionally a property and or userProperty can be created from the
>> value entered by the user.

> No userProperty, please.  These should strictly be reserved for
> properties set on the command line or via the child elements of <ant*>

Wasn't fully aware of this. Let me know and I'll take it out and
post an update.

> Stefan

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



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

View raw message