> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> But I don't feel comfortable with adding magic properties for
> situations like the javac/jikes one in general. Unfortunately I don't
> have a better solution for all situations at hand yet.
>
I agree. Such properties seem like backdoor entries into the task bypassing
the normal interface used to configure the task.
What I had thought would work would be to define configurations for certain
tasks
<taskconfig task="javac">
<attribute name="compiler" value="Jikes"/>
<attribute name="pedantic" value="on"/>
</taskconfig>
Effectively these attributes would be set by default for the task when it is
executed. They could then be overridden on a per-task basis. If you know
that Jikes can't compile something, you could force a classic compile, etc.
Such configs could be defined in ${user.home}/.antconfig.xml.
This could also be used for mapping tasks to concrete implentations which
may be useful in the J2EE arena where there are many vendor implementations
of various tools.
<taskconfig task="jspc">
<implementation task="wljspc"/>
</taskconfig>
It could even use some form of if processing
<taskconfig task="jspc">
<implementation task="wljspc" if="weblogic.available"/>
<implementation task="jasper" if="tomcat.available"/>
</taskconfig>
We could also support nested elements which would automatically get added to
the task invocation too. This would allow you to configure options which
make sense in only some implementations
<taskconfig task="javac">
<attribute name="compiler" value="Jikes"/>
<jikes pedantic="on"/>
</taskconfig>
What do you think?
Conor
