ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: Building Ant 1.7beta
Date Thu, 31 Aug 2006 19:26:21 GMT
Stefan Bodewig wrote:
> you'd just be asking for classloader problems if you have two different
> versions of Ant inside the same Java VM while compiling Ant or running
> the Unit tests, aren't you?

This is another pet peeve of mine: apparently when you run the Ant unit 
tests, the version of Ant it is testing is the version of Ant running 
build.xml, *not* the (presumably modified) source code in your svn 
checkout. This is just a mistake, I think. All of the unit tests ought 
to be forked and ought to use the Ant binary that you are developing. Am 
I really the only one to have been burnt (repeatedly) by this? I keep on 
writing some code, writing a test, hmm test fails. OK tweak the code to 
print some diagnostics... they're never printed. Hmm. Add "throw new 
Error();" into the middle of a method I'm sure must be executed; still 
nothing. Tear out hair, then remember I'm not even running the code I 
just wrote at all.

Anyway, along with the 1.6.5-vs-trunk issue I eventually just fixed this 
for myself by writing a wrapper script (very much like the bootstrap.xml 
you mention) that runs under 1.6.5 yet builds trunk and ensures that 
tests are run by the right copy of Ant. Part of my NB project setup but 
would work independently of any IDE too.

>> Similarly you could not use a bundled Ant binary on Linux to run
>> ant/build.xml targets (or use Bash completions...).
> The first thing I'd do is throw out the bundled binary and install the
> last released version myself anyway ;-)

Not always easy to throw out an RPM (other RPMs may dep on it).

> My rent is paid by working on projects that don't use Ant at all 8-)



--  x22801*i%29%2B1

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

View raw message