>>>>> "SM" == Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
SM> Timo Koepke wrote:
>> my name is Timo, and I want to become an Ant developer.
SM> <IMHO>not a great start: "want to become" sounds like an
SM> order.</IMHO>
Sorry, but IMHO Timo didn't sound demanding in any way.
Maybe it is because I'm german too and would translate "want to
become" into german as "m�chte werden" which is far more like "would
like to be".
>> -computed property values (the syntax classpath="${classpath}" is
>> a good starting point)
SM> what do you mean?
Probably some kind of functional extension along the line of
"${prop1}.equals(${prop2})" or similar.
Sam has convinced me that making Ant yet another programming language
is not the right thing to do - although I could see benefits from such
an extension.
>> -changing the current directory on invoking sub-Ants (for example,
>> to prevent clobbering of output files given to the Exec task)
SM> hmmmm, one might want all the output in the same directory. -0 to
SM> this
So maybe make it an option?
>> -support for additional languages like scheme inside Ant (could
Timo, take a look at the Script task in the optional package. Maybe
you could make your personal scheme compiler BSF supported?
Then again Ant already supports execution of scripts via this task -
why not add execution of another language as well.
SM> oh god... do we really need this? I still don't like the ability
SM> to include scripting... are we going to add every possible
SM> programming language inside build files?
Of course one can argue about it. It is always possible to call
scripts in any language via the Exec task.
I just suppose it's more convenient to have specialized - and don't
forget _optional_ - tasks for common languages.
