On Fri, 03 Mar 2006, Jesse Glick <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>> putting even more modifications into the current task (adding a new
>> JUnitResultFormatter subclass for ignored tests, for example) will
>> make it even more convoluted than it currently is.
>
> Of course. The
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Glick
> Sent: Saturday, 4 March 2006 5:50 AM
> To: dev@ant.apache.org
> Subject: Re: Junut4
>
> Stefan Bodewig wrote:
> > putting even more modifications into the
Stefan Bodewig wrote:
putting even more modifications into the current task (adding a new
JUnitResultFormatter subclass for ignored tests, for example) will
make it even more convoluted than it currently is.
Of course. The question is how this additional complexity balances
against the duplica
On Thu, 02 Mar 2006, Jesse Glick <[EMAIL PROTECTED]> wrote:
> Kev Jackson wrote:
>> That would certainly be optimal. (+1 for seperate task)
>
> If others agree, should the existing 4 support in be
> reverted?
I feel that the changes between JUnit3 and JUnit4 warrant a new task,
putting even mor
Kev Jackson wrote:
That would certainly be optimal. (+1 for seperate task)
If others agree, should the existing 4 support in be reverted?
It can be considered a proof of concept in its current state. My main
concern is that making it a separate task would require people to change
their bui
Kev Jackson wrote:
+1 for a separate task, packaged in an Ant library. This one could be
release before Ant 1.7.0 which would give people using JUnit4 more
support sooner.
Personally I'd even prefer the JUnit team to provide that Ant library
so they have to keep up with their API changes them
Jesse Glick wrote:
Steve Loughran wrote:
There was some discussion of junit4 implications in the ant-user mail
list,
Ah, thanks for the pointer, missed that before. Some things I can
extract from that thread:
- ignored tests ought to be reported (currently they are just silently
skipped)
+1 for a separate task, packaged in an Ant library. This one could be
release before Ant 1.7.0 which would give people using JUnit4 more
support sooner.
Personally I'd even prefer the JUnit team to provide that Ant library
so they have to keep up with their API changes themselves 8-)
That
On Wed, 01 Mar 2006, Jesse Glick <[EMAIL PROTECTED]> wrote:
> Not really clear to me at this point whether the significant
> features of JUnit 4 can be accommodated comfortably inside
> or whether a separate task would be better.
+1 for a separate task, packaged in an Ant library. This one coul
On Wed, 01 Mar 2006, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Martijn Kruithof wrote:
>> Furthermore I thought junit 4 would get rid of the distinction
>> between failure and error, wouldn't we want to remain in-line with
>> this new junit behaviour when running junit 4 testcases in an junit
>>
Steve Loughran wrote:
There was some discussion of junit4 implications in the ant-user mail
list,
Ah, thanks for the pointer, missed that before. Some things I can
extract from that thread:
- ignored tests ought to be reported (currently they are just silently
skipped)
- should support s
Martijn Kruithof wrote:
Isn't this a bit premature, junit 4 isn't even "out" yet.
shipped last week. Gump is still recovering.
Furthermore I
thought junit 4 would get rid of the distinction between failure and
error, wouldn't we want to remain in-line with this new junit behaviour
when runn
12 matches
Mail list logo
