Another model to look at is <sql> task. It uses CDATA but it also allows you to put yout commands in files and expand variables inside.
Take a look. Jose Alberto ----- Original Message ----- From: "stephan beal" <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Friday, March 22, 2002 3:17 AM Subject: Re: updated patch set > On Friday 22 March 2002 03:43, you wrote: > > ----- Original Message ----- > > From: "stephan beal" <[EMAIL PROTECTED]> > > > > > Project.toBoolean(): > > > If passed null, it now treats that as false. i hope that's not evil? > > > > -1 > > > > Don't touch things like that until you're truly confident it won't break > > backwards compatibility. In this case it likely would. > > point taken. That's the only place where i'm not certain of compatibility. > > > > I agree with Diane on this. We'll hold off reviewing for commit until this > > is done. You may be able to reuse other pieces of Ant to implement the > > <command> sub elements, although not sure off what off the top of my head - > > check out tasks that execute other tools. > > i think <exec> may work here. i don't want to do away with the cdata > handling, though, because i already use it ;). My company's test server > process goes like this: > > 1) developer develops. Commits his code. That generates a CVS mail. > 2) developer fwds me the cvs mail (it has the version of each file he wants > installed on the test server). > 3) i run that through a script which generates cvs update commands. > 4) <cvs>script's contents</cvs> does the work. > > That's simple to automate. Consider automating: > <cvs> > <commandline> > <arg value="up"/> > <arg value="-r"/> > <arg value="some/file.java"/> > </commandline> > <commandline> > <arg value="status"/> > <arg value="some/other/file.java"/> > </commandline> > </cvs> > > i completely agree that it "fits the ant mould", i'll also be quick to point > out that it's nearly impossible to 100% reliably automate the creation of > such xml. i cannot imagine many uses for the above syntax when someone could > just do: > <cvs command='up -r some/file.java'/> > <cvs command='status some/other/file.java'/> > > (My patch is essentially just a foreach wrapper around this exact syntax.) > > If you had to hand-write, or write code that would automate the generation of > your xml, which of the two above syntaxes would you prefer to work with? > > Of course, one possible middle ground could be: > <cvs> > <commandline value="up -r some/file.java"/> > <commandline value="status some/other/file.java"/> > </cvs> > > That doesn't look too daunting, except for when you're generating your XML > from perl/shell/makefiles: you'll have to care for proper quoting of the > filenames (or web designers LOVE to use filenames with spaces in them). Seems > more trouble than it's worth when you can simply dump it all in: > <cvs><![CDATA[blahblahbalh]]></cvs> > > i agree, either of the above 3 fit the ant look and feel better than > cdata=commands does, but you've gotta admit that my way's easier to automate > code for ;), so i don't want to remove it, just offer a different syntax. i > also plan on adding support for reading the command list from a file. The > support exists in my "work copy", i just need to port it. > > > ----- [EMAIL PROTECTED] > http://qub.sourceforge.net - http://radioaqtiph.sourceforge.net > http://www.countermoves.net - http://stephan.rootonfire.org > "Unix: the shell is your oyster." > > > > > -- > 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]>
