Hello Stefan,
Tuesday, November 13, 2001, 1:43:16 PM, you wrote:
> On Sat, 10 Nov 2001, Ulrich Schmidt <ulrich.schmidt@gmx.net> wrote:
>> Input task allows user interaction during the build process by
>> displaying a message and reading a line of input from the
>> console (System.in).
> 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:
<input
message="All data is going to be deleted from DB continue (y/n)?"
validargs="y,n"
addproperty="build.abbort"
/>
<condition property.build.abbort="n">
<!-- ^ not implemented yet -->
<fail> Build abborted by user.</fail>
</condition>
instead of:
<input
message="All data is going to be deleted from DB continue (y/n)?"
validargs="y,n"
exitargs="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*>
> IMHO.
Wasn't fully aware of this. Let me know and I'll take it out and
post an update.
> Stefan
> --
> To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
Cheers,
Ulrich
--
To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
|