> - 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

This solution of an rmicdir task (or some such name) that would reflect into
all classes and find the remote classes would be a decent thing to do.

> 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.

I don't think that you've proved that control structures are necessary. I
think that you've proved that there are task types that can be introduced
that make life easier for the XML writer and which do more of the logic.

> (it would be nice also to have a serialver task)

Sure. Write one up. :)

> 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?

That's not a bad idea as well. Having a $HOME/.antrc or some such would not
be a bad thing imho.

.duncan