ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Maher \(Laptop\)" <jma...@nctimes.net>
Subject Re: Junit task
Date Tue, 20 Jun 2000 20:12:30 GMT
"Let it be beautified later" is not reasonable.  When will 'later' come.
Just do it now.
JohnM

----- Original Message -----
From: "Thomas Haas" <thomas.haas@softwired-inc.com>
To: <ant-dev@jakarta.apache.org>
Sent: Tuesday, June 20, 2000 12:39 PM
Subject: Re: Junit task


>
> Thanks for all the support. Prior to start and submitting work, I need to
> synch with our latest development in the office. So you will get something
> by tomorrow at best (note: we have GMT +1 here).
>
> JUnit is mature enough to get into ANT, it needs some tweaking so:
> - Better support for failing or not failing on errors. The thing is great
> for automated builds, but a little pain for interactive development (read:
> looking for bugs in the automated build :-)
> - The output system needs some tweaking.
>
> Dependencies:
> The JUnit task depends on two things:
> - The Path object discussed in lengths already.
> - A different framework to exec processes from Ant.
>
> Path Object
> I consider the state mature, although the Tokenizer provided by Conor
would
> make it more readable than my hack on StringBufffer. Also, only very late
I
> finally understood what Project.resolveFile is used for, which means that
> Path needs a fix.
> Suggestion: I add support for resolve file and commit a first version and
> let it be beautyfied later, maybe by Conor himself (I hope to not get any
> names wrong here).
>
> Execution Framwork
> Features:
> - it runs on Windows 95/98
> - it has a timeout feature, which kills a hanging process after some time
> (very handy for tests :)
> - stdout/stderr of the subprocess can be captured and processed easily.
> Support for feeding stuff via stdin is available as well.
>
> Missing:
> - Change of current or running directory is not supported (let me talk
about
> this further down).
>
> The execution framework is quite big, so it needs some time to digest.
>
> Suggestion: I will brush things up, put everything into optional, make it
> compile optionally (if the JUnit framework is found) and commit it. Than
we
> fix, improve and discuss about things (execution framework).
>
> - tom
>
> PS
> Current Directory for processes in Java:
> As others found out, there is no way to change the current working
> directory. The exec task uses some helpers to accomplish this.
Unfortunatly,
> they do not work everywhere. Therefor I ommitted support in the Execution
> framework first, until a clean solution is provided.
> Note: support for the current behaviour can be added within minutes.
>
>
>
> From: <rubys@us.ibm.com>
> >
> > Conor MacNeill wrote:
> > >
> > > OK, what do we need to do to get the JUnit task in there ?
> >
> > It is easier to ask forgiveness than permission.
> >
> > Seriously, I doubt that anybody will question an optional task that is
> > conditionally compiled.
> >
> > - Sam Ruby
> >
>
>
>


Mime
View raw message