You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by bo...@apache.org on 2003/11/21 11:52:23 UTC

cvs commit: ant/proposal/sandbox/dotnet .cvsignore README

bodewig     2003/11/21 02:52:23

  Added:       proposal/sandbox/dotnet .cvsignore README
  Log:
  Initial commit so people know where I want to go
  
  Revision  Changes    Path
  1.1                  ant/proposal/sandbox/dotnet/.cvsignore
  
  Index: .cvsignore
  ===================================================================
  build
  
  
  
  1.1                  ant/proposal/sandbox/dotnet/README
  
  Index: README
  ===================================================================
  dotnet sandbox README
  =====================
  
  Author:
  -------
  
  Stefan Bodewig, but feel free to go ahead and modify to your liking.
  
  Goal:
  -----
  
  Provide a simple infrastructure to execute .NET applications from
  within Ant for different VMs so that the user doesn't have to change
  the build file when she wants to run Mono on Linux and Microsoft's VM
  on Windows.
  
  This sounds far more ambitioned than it actually is.
  
  Short term goals are:
  
  * 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).
  
  * A <nant> task.
  
  * A <msbuild> task - if only for the fun of having it.
  
  Mid term goals:
  
  * A <nunit> task.
  
  Those tasks should end up in an antlib of their own in order to be
  distributable independent of Ant.
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: cvs commit: ant/proposal/sandbox/dotnet .cvsignore README

Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 24 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
> Stefan Bodewig wrote:
>
>> 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

Done.

>> On Fri, 21 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
>>
>>>+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.

OK, I see.

> 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.

Yep, something similar has been started by Stephane for JUnit (running
tests in a separate VM but sending the results directly to Ant without
"tunneling" through logfiles.

> This is all 1.7-timeframe stuff, but could be very cool.

Sure.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: cvs commit: ant/proposal/sandbox/dotnet .cvsignore README

Posted by Steve Loughran <st...@iseran.com>.
Stefan Bodewig wrote:
> On Fri, 21 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
> 
>>bodewig@apache.org 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: cvs commit: ant/proposal/sandbox/dotnet .cvsignore README

Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 21 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
> bodewig@apache.org 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.

>>     * 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.

>>     * A <msbuild> task - if only for the fun of having it.
> 
> eventually; could be a followon to <nant>

It is, just look at the code.  They share almost everything.

>>   Mid term goals:
>>     * A <nunit> task.
> 
> yes please!

Mid term 8-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: cvs commit: ant/proposal/sandbox/dotnet .cvsignore README

Posted by Steve Loughran <st...@iseran.com>.
bodewig@apache.org 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

>   
>   * A <nant> task.

+1; would be nice if we could have a nant listener that would feed into 
Ant's reporting levels.

>   
>   * A <msbuild> task - if only for the fun of having it.
> 

eventually; could be a followon to <nant>


>   Mid term goals:
>   
>   * A <nunit> task.

yes please!

This may need some nunit tuning.

>   
>   Those tasks should end up in an antlib of their own in order to be
>   distributable independent of Ant.
>   

Also:

<al>, <ngen>, maybe a couple more.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org