rubys@us.ibm.com wrote:
> 1) Requirements. What are the types of problems that people need to solve..
I gave a look at the problems i see in my build files, and this is what i have:
- lots of keysubst tasks, in fact they could -and should- be removed by using
the new filter
ability of copydir. The only issue here is that i need to be able to define
locally my filters.
- lots of rmic: for that one i had to write a generator of tags that takes the
list of implementation
class and generates the <rmic> tags to build the stubs for them. A for loop is
an easy solution,
but we might as well extand the functionallity of rmic so that it can discover
the remote classes
in a folder and generate the stubs for them
Ok, so far I've just proved that foreach *might* be useful in sporadic
situations but the need for
it reflects more other problems in the existing tasks.
(it would be nice also to have a serialver task)
>
> 2) Enablement. Users are able to provide their own task definitions, and...
Can we consider some kind of extension mecanism to ant? I find that having to
define <taskdef>
in each project is a pain (especially is you have >10 projects...). I've seen
that you can read default
properties from your home directory, why not have that also for default
taskdefs?
Ludovic.
|