The approach I was considering taking was getting the taskdefs from the Project and the properties file. Then the element names can be retrieved using the tasks class. This means that tasks that do not extend Task will also be handled.
The responses in this thread have all been with regards to the implementation detail. Do people think that this is a good idea? If the pattern for a task was extended so each task must have accessors then using reflection would be the way to go. What was the reason for only requiring tasks to have an execute method? I don't think it would be an unreasonable development burden for accessors to be required. -John K On Fri, 2002-03-22 at 01:06, Erik Hatcher wrote: > > ----- Original Message ----- > From: "stephan beal" <[EMAIL PROTECTED]> > > > > On Friday 22 March 2002 00:28, [EMAIL PROTECTED] wrote: > > > I have identified two approaches to achieve this. One is to get all > > > tasks to implement a toXML method. These methods would return an XML > > > String representing that task instance. This obviously requires a lot > > > of code changes. > > > > With a serialize-to-xml framework it becomes pretty simple. i know one > exists > > in Java, but i can't remember the name. > > I don't think its quite that simple.... how would such a framework get > attribute values and such to reconstruct the XML? There are typically no > getters on Ant tasks to return back attributes and sub-elements. > > And also, keep in mind that an Ant task does not necessarily extend Task.... > the only requirement to being an Ant task is implementing an execute() > method! > > Erik > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
