Also notice that you cannot reproduce the REAL project XML from the content of the tasksI hadn't thought of this as my use case doesn't worry about properties (see
the reason being that tasks are not aware of property expansion. By the time calls are made
into the task all property expansion has already happened. The resulting XML, IMO, is useless.
90% of the meaning of an XML buildfile is in the properties.
below).
In other words this is the wrong way to go. If ANT1.x decides to move into an all UnknownElement orI have a code generator which produces a different number of Java classes
RuntimeConfigurable approach, then most of the issues above will disappear. But still I have a question
why do you want to reconstitute the ANT1.x XML?
based upon the input). The names of these classes are also dependent on
the input. To make it that bit easier to work with the generated code I also
generate a build.xml file. I currently do this by hand crafting the XML using
StringBuffer.append(...). For example if I add a copy task to the project, I
simply do something like:
buff.append("<copy file=\"").append(sourceFileName).append("\"");
buff.append(" tofile=\"").append(destFilename).append("\"");
buff.append(" />\n");This is fine for the limited tasks I currently use. I was thinking that in the
future I may require to add other tasks and as such the amount of code I need
to write increases. The responses on this thread have been helpful and I
now realise that my simplistic approach will not work. The object model
approach that Adam discussed seems to be the best way to achieve what
I require.
-John K
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
