Allows user interaction during the build process by prompting for input. To do so, it uses the configured InputHandler.
The prompt can be set via the message attribute or as character data nested into the element.
Optionally a set of valid input arguments can be defined via the validargs attribute. Input task will not accept a value that doesn't match one of the predefined.
Optionally a property can be created from the value entered by the
user. This property can then be used during the following build
run. Input behaves according to property
task which means that existing properties cannot be overriden.
Since Ant 1.6, <input> will not prompt for input if
a property should be set by the task that has already been set in the
project (and the task wouldn't have any effect).
A regular complaint about this task is that it echoes characters to the console, this is a critical security defect, we must fix it immediately, etc, etc. We know it leaves something to be desired, but the problem is Java, not Ant. There is nothing we can do to stop the console echoing.
IDE behaviour depends upon the IDE: some hang waiting for input, some let you type it in. For this situation, place the password in a (secured) property file and load in before the input task.
| Attribute | Description | Required |
| message | the Message which gets displayed to the user during the build run. | No |
| validargs | comma separated String containing valid input arguments. If set, input task will reject any input not defined here. Validargs are compared case sensitive. If you want 'a' and 'A' to be accepted you will need to define both arguments within validargs. | No |
| addproperty | the name of a property to be created from input. Behaviour is equal to property task which means that existing properties cannot be overridden. | No |
| defaultvalue | Defines the default value of the property to be created from input. Property value will be set to default if no input is received. | No |
Since Ant 1.7, a nested <handler> element can be used to specify an InputHandler, so that different InputHandlers may be used among different Input tasks.
| Attribute | Description | Required |
| type | one of "default","propertyfile", or "greedy". | One of these |
| refid | Reference to an InputHandler
defined elsewhere in the project.
|
|
| classname | The name of an InputHandler subclass. |
|
| classpath | The classpath to use with classname. | No |
| classpathref | The refid of a classpath to use with classname. | No |
| loaderref | The refid of a classloader to use with classname. | No |
<input/>
Will pause the build run until return key is pressed when using the default InputHandler, the concrete behavior is defined by the InputHandler implementation you use.
<input>Press Return key to continue...</input>
Will display the message "Press Return key to continue..." and pause the build run until return key is pressed (again, the concrete behavior is implementation dependent).
<input
message="Press Return key to continue..."
/>
Will display the message "Press Return key to continue..." and pause the build run until return key is pressed (see above).
<input
message="All data is going to be deleted from DB continue (y/n)?"
validargs="y,n"
addproperty="do.delete"
/>
<condition property="do.abort">
<equals arg1="n" arg2="${do.delete}"/>
</condition>
<fail if="do.abort">Build aborted by user.</fail>
Will display the message "All data is going to be deleted from DB continue (y/n)?" and require 'y' to continue build or 'n' to exit build with following message "Build aborted by user.".
<input
message="Please enter db-username:"
addproperty="db.user"
/>
Will display the message "Please enter db-username:" and set the
property db.user to the value entered by the user.
<input
message="Please enter db-username:"
addproperty="db.user"
defaultvalue="Scott-Tiger"
/>
Same as above, but will set db.user to the value
Scott- Tiger if the user enters no value (simply types
<return>).