ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan \"Rambius\" Ivanov" <>
Subject Re: <input>, but for paths...
Date Wed, 15 Feb 2006 18:11:32 GMT

<input> task does not read the user input. Instead it
delegates the reading to InputHandlers [1]. In short
you should write an extension of InputHandler and
create the dialog in it. Then pass the fully qualified
name of your input handler to -inputhandler option of
ant launching script. I collected some more
information on ant's input handlers in an article
called "Extending Ant Input Abilties", which you can
find at [2].

While it is a good exercise to play with the handlers,
I think that <input> task spoils the idea of the
automation. I prefer to store the different settings
in  differen properties/xml files and load one of
those files depending on the context/environment of
the build. Of course, if in your case the path is
completely arbitrary, you have less choices.



--- Rich Wagner <> wrote:

> I was looking through the online Ant manual
> recently, looking for 
> something like <input>, but which would display
> either an "open" or 
> "save" dialog, i.e. what you typically see if you
> choose "File: Open..." 
> or "File: Save..." in an application.  Alas, I found
> no such task, so I 
> instead wrote tasks and targets which would use
> <input> and would ask 
> the user to type paths: not as user-friendly...
> Has this sort of task ever been considered as an
> addition to Ant?
> (I realize Ant can't assume it's running on a
> machine with a display, 
> mouse, etc.; i.e. that it may find itself on a
> "headless" computer.  But 
> in that case this proposed <input> variation would
> resort to a 
> stdout/stdout-based prompting...)
> Thanks in advance,
> Rich Wagner
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

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

View raw message