I can see that this is much more complex than I originally thought. :-) A few thoughts:
You could probably get away with passing in properties using NAnt's command line interface (using "-D:<name>=<value>") -- but then, there is no way to get messages back from the subprocess. This seems to be the key reason for the need for the XML protocol. It seems like the use of an XML protocol would require a handler on the NAnt side, and for TCP loopbacks, you would need some sort of listener process. The protocol would need to be understood by any process with whom Ant communicates -- it would require some coordination with the NAnt developers. One of my immediate needs is to be able to run NUnit tests in our build process. It looks like the simplest option for now is to build an <nunit> task for Ant. Is anyone else interested in this? Brian -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Monday, September 09, 2002 4:20 PM To: Ant Developers List Subject: Re: nantcall task (was: Optional task: Visual Basic.NET compile) ----- Original Message ----- From: "Felder, Brian" <[EMAIL PROTECTED]> To: "'Ant Developers List'" <[EMAIL PROTECTED]> Sent: Monday, September 09, 2002 3:41 PM Subject: nantcall task (was: Optional task: Visual Basic.NET compile) > I like the approach of calling NAnt from Ant. Just out of curiosity, I built > a <nantcall> task. I'm attaching a first cut at this, with tests. It's > extremely simple: it takes a NAnt buildfile name, and a space-separated list > of targets. [NANT_HOME]/bin must be in the PATH for this to work. comma separated, surely. Spaces are valid in target names. > > I'm not sure if there are issues related to using this within Cruise > Control. If it works as Curt says, perhaps this would be a good way to have > Ant drive a build process that includes both Java and .NET code. > > Brian one thing that <ant> does is pass down references and properties, messages sent from below are passed up, things we have to replicate across processes. We have the same problem with <nantcall> as one would have with <subant> with fork=true, if that were ever implemented. The obvious solution here is (and its a good one) -define an XML wire protocol that can be used between an ant process and a sub process. -use that wire protocol over std-in and std-out, or over tcp loopback If done right, the same protocol would work for nant, ant w/ forking and remote access a la rant. SOAP would seem the obvious choice, though it doesnt have a stdio transport that I am aware of. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> **************************************************************************** This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
