ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Glanville" <>
Subject RE: build.classpath and tinderbox builds
Date Thu, 04 Jan 2001 13:53:05 GMT
First, let me apologize for not sending plain text last time I mailed.  As a
way of apology, let me offer a comic ;-)

now, back to some serious stuff.

> -----Original Message-----
> From: Sam Ruby []
> > I'm a little confused as to how the position of the system libraries
> alters the
> > results of your build.  Can you provide a small example of 
> how this is
> the
> > case?
> Some projects check in an ant.jar, and specify that jar in 
> the classpath in
> their build.xml.
> Now I put a different ant.jar into my CLASSPATH environment variable
> (a.k.a., ${java.class.path}).
> Which one wins?  Depends on the order of the final classpath 
> passed to the
> compiler.

I guess you could ask yourself, "Why is the libraries of my build tool being
put into the classpath of my environment?"  Especially when, if needed, they
could be explicitly included.

In other words, instead of modifying the order of the classpath, try
removing the build-tools runtime libraries.  The way that I've tested this
is to remove the line
from the method
Now, if you've modified your classpath environment variable to alter the
behaviour of ant (i.e.: added things to env so they get included in the
build), then the above has the side affect of removing that.  However, I
believe that this isn't necessarily a bad thing.  For recreatability
intentions, I don't like relying upon environment variables in my build
environment - they aren't always captured in logs, and they have a "magic"
feel to them.

Please let me know if this would help you, as my refactoring also added an
includeAntRuntime attribute.


View raw message