First, let me apologize for not sending plain text last time I mailed. As a way of apology, let me offer a comic ;-)
http://www.comics.com/creators/speedbump/archive/speedbump-20001228.html now, back to some serious stuff. > -----Original Message----- > From: Sam Ruby [mailto:[EMAIL PROTECTED] > > > 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 classpath.addExisting(Path.systemClasspath); from the method Javac.getCompileClasspath(); 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. Jay
