ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rhino" <>
Subject Re: Improving Tasks
Date Fri, 22 Oct 2004 15:12:05 GMT

Your entire reply was very useful but I have a followup question re Question
2: if the existing <input> task can display a textfield with two buttons in
a popup dialog, shouln't I be able to do the same thing with radio buttons
or drop down lists instead of a textfield?


----- Original Message ----- 
From: <>
To: <>
Sent: Friday, October 22, 2004 9:49 AM
Subject: AW: Improving Tasks

> I'm starting to get the hang of Ant now and am starting to think about
developing some tasks to
> increase what it can do.

I suggest reading these manual entries

> However, before I start developing entirely new tasks, I thought I might
take a whack at improving a
> few existing tasks. One improvement I'm thinking about involves the core
task <input>. I'd like to
> enhance it in a couple of ways:
> 1. Provide for a masked input field so that it could be used to prompt for
a password that would remain
> unreadable to anyone looking over the users shoulder. (I envision adding a
'mask="true"' parameter to
> make that possible with the default for 'mask' being 'false'.)

<input> provides InputHandler for these.
For masking see the article at

> 2. I'm thinking about adding the capability of having a radio button group
and/or drop down lists
> so that there are some additional ways for users to provide input.

Radio buttons usually are part of a graphical UI - Ant has no. So good luck
for porting
that to command line :)

> How would I get my hands on the source code for the existing task without
stepping on anyone's toes?

Download the source and modifiy it as it suites your needs.
If think it works, open a Bug and apply the path (dont forget the docs and
And maybe a committer will commit that ...

Before the commit noone (except you) will have that and after everyone.

> Would my enhancements have to be approved in advance or would I submit
them and then go through some
> kind of voting process by Ant users with my changes discarded if I didn't
"win" the vote?

If your patch wont be accepted (by committers, not by users) you can do
another thing:
bundle that class in a jar, create a antlib.xml and provide that as external
task. Maybe you
will change the package name then.

>What testing would I have to do to satisfy the Ant community that my code
was clean enough to implement?

JUnit test. See the testcases for the other tasks.
You can do more or less - more is better :)
There is no guideline how much you _have_ to test...

> Or should I develop an entirely new task with the intent of deprecating
<input> and replacing it with
> my 'better' task (assuming I can get it to work ;-)?

As an external library. Advantage: you are your own committer :)

> By the way, is this the right list for these sorts of questions or should
I be asking on the
> developers list?

AFAIK the committers are listening here also, so chances are good to get an

There is no real frontier between user and developer - so post as you think.
IMHO these can go to DEV, but it´s not unusual here...


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

View raw message