On Fri, 21 Nov 2003, Steve Loughran <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
bodewig 2003/11/21 02:52:23 * A <dotnetexec> task that can be used as <dotnetexec executable="ExampleCsc.exe"/> without testing for the environment (see the dotnet.xml build file for Ant's tests as an example for what may become simpler with this).
+1, let people provide the path of a launcher if needed
It is already there. I've named the attribute vm, not sure whether this is appropriate for .NET folks, though.
BTW, we could probably change <csc> to default to mcs as executable if not running on Windows, that would make build files easier to port.
+1
* A <nant> task.
+1; would be nice if we could have a nant listener that would feed into Ant's reporting levels.
I don't think it is possible to write on without making it LGPLed at the same time.
that side of things would go into nant or an sf project; ant side would just parse the stream.
Actually it makes me think of a broader want of mine -the ability to run a forked or remote and and have log info chain across the wire -messages, exception traces, &c.
Before anyone says 'soap', I dont think soap is right as it wouldnt be progressive enough; an invoke() call would only return when invocation finished, and I want streaming.
But we could have some XML wire format to listen to, an XML-marshall-listener for both Ant and Nant, and an XML-unmarshaller ant-side (and nant side, but that is their problem), & stream stuff over stdio, telnet, ssh, http, whatever. We could then do an AntServlet that would run ant on a server...
This is all 1.7-timeframe stuff, but could be very cool.
Mid term goals: * A <nunit> task.
yes please!
Mid term 8-)
oh, do you mean next week
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
