In this case, only the class corresponding to sometask needs to extend org.apache.tools.ant.Task.
Well, technically, it does not even have to extend Task. An Ant task simply must have an execute() method, that is all. But its recommended to extend Task for logging and Project access.
Now consider the following build file for which I don't understand how to create the ant task.
<target name="somefancytarget"> <somefancytask attribute1="bla"> <subfancyelementA attribute2="bla"> <subfancyelementB attribute3="bla"/> <subfancyelementB attribute3="bla"/> </subfancyelementA> </somefancytask> </target>
Can subfancyelementA and subfancyelementB still be simple container classes?
Yes. The same mechanism for populating a Task with element/attribute information is used from your custom task and as far down as you want to go. No difference whatsoever, actually.
If so would the class corresponding to subfancyelementA need to implement addSubFancyElementB, addConfiguredSubFancyElementB, or createSubFancyElementB?
Yup.
But there is another way to do this with Ant 1.5. Implement the DynamicConfigurator interface to make it more dynamic. This might be overkill for what you're doing, but you ask a generic question, and you get a generic answer! :) But, seriously, if you need/want to have the element names be dynamically available, then DynamicConfigurator is how to do it.
If the above guesses are wrong, can someone explain what I should be doing?
You're on the right track.
Erik
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
