From: <[EMAIL PROTECTED]>
> <snip/>
> > Also notice that you cannot reproduce the REAL project XML from the
> > content of the tasks
> > 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.
> I hadn't thought of this as my use case doesn't worry about properties
> (see
> below).
>
Ahh, but once you think on changing the entire ANT framework, then you cannot
just think on your limited case scenario.
> > In other words this is the wrong way to go. If ANT1.x decides to move
> > into an all UnknownElement or
> > 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?
> I have a code generator which produces a different number of Java classes
> 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");
>
Why don't you use JDom instead of StringBuffers?
Using JDOM you actually can build your buildfile *easily* as an XML tree
and then you just ask JDOM to Serialize it into a file or watever.
In other words you can achieve what Adam was talking about today.
For you limited case.
Jose Alberto
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
