+1 (no time to dig into the guts of it, but I'm all for this addition)
----- Original Message ----- From: "Stefan Bodewig" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, February 25, 2002 11:20 AM Subject: [PROPOSAL] simple input framework > ... or wait fo my mail ... > > Current CVS has an <input> task written by Ulrich Schmidt (who may > have left ant-dev, that's why I cc him). This implementation directly > reads input from System.in, which will be a big problem when running > Ant from an IDE or Antidote. > > In proposal/sandbox/input I've started a very simple framework that > allows tasks to ask for user input and allows IDEs to intercept these > requests - it also allows input to be read from a properties file, > allowing interactive builds to be run in an unattended batch mode. > > There are two minor changes two Project and Main. Project now holds > an instance of an InputHandler and provides access to it, Main > provides a way to chose this handler on the command line. > > Instead of reading input from System.in, an implementation of the > InputHandler interface, that consists of the single method > > void handleInput(InputRequest request) throws BuildException; > > is asked to take care of it. > > The request encapsulates the prompt (which is the key for properties > loaded from the properties file at the same time) and may perform > input validation. > > The DefaultInputHandler sends the prompt to System.out, which means it > will end up in Ant's logging system, and query user input from > System.in - reprompting until the user has provided some valid input. > > Two other implementations are there as well - PropertyFileInputHandler > for unattended builds and SwingInputHandler which is nothing more than > a proof of concept (and very ugly indeed 8-). > > I don't like the way the name of the property file gets passed to > PropertyFileInputHandler - currently a system property - but couldn't > come up with a better one without breaking the isolation between > InputHandler and Project. > > See the README file for more details. > > I'd like to see this proposal being accepted for the 1.5 time frame so > that we don't distribute <input> with its current limitations. > > Stefan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
