ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Ant test framework
Date Tue, 28 May 2002 03:07:46 GMT

----- Original Message -----
From: "Conor MacNeill" <>
To: "Ant Developers List" <>
Sent: Monday, May 27, 2002 7:03 PM
Subject: Re: Ant test framework

> wrote:
> > This is part of an email conversation between Conor and myself about
> > getting the build file test framework available as another deliverable
> > ant.
> >
> > In Maven, we've written several project specific tasks that need to be
> > tested on a regular basis, and rather than subsume the source code from
> > Ant, we'd much prefer the 'Ant Test Framework' to be available as a jar
> > file so that other projects can specify it as a test dependency, and use
> > it.
> >
> > So the proposal is that for Ant 1.6 and beyond the test classes needed
> > test build files be packaged up as another jar and made a deliverable
> > the optional jar is.
> >
> > Votes: +1/-1/+0/-0?
> >
> > I'm willing to make a new build file for ant to build the test framework
> > and package it as a jar (i.e. +1 from a non-committer).
> As I said, Steve has been looking at this. I can't remember the latest
> thinking. I've looked a bit further just now and I think that perhaps
> the easiest thing is just to move BuildFileTest into the main source
> tree (and hence ant.jar) without moving it in its package namespace. The
> Ant tests would continue to function as is and task developers would not
> have to copy and paste code to access test facilities.

I think Mageshe's concept, which I was happy with, was to have a separate
jar, number it ant-test-framework1.5.jar, or the like, and make *no*
guarantees about forward/backwards compatibility.

If we publish the tests as part of the core API, then it is frozen for
eternal support.

seems to me that there is something odd about the fact that we have to code
our build file tests in java. Surely we should be able to do a lot of them
(all the ones where we make assertions about the state of properties, or
expect assertions), using a more declarative XML style...


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message