Howdy. Okay, I've heard the news about the 'build.sysclasspath' property, and that's great for controlling whether and how ant will use the $CLASSPATH of my invoking shell when performing <javac> tasks, but there appears to be another issue with the 'destdir' attribute of the <javac> task. Specifically, it appears that ant ALWAYS appends the value of the 'destdir' attribute to the value of the 'classpath' attribute before invoking javac. This seems perfectly reasonable, but I'm wondering whether it's possible to stop this behavior. My reason for wanting this is that we do development in a "shared sandbox", which essentially means that we have developers working in multiple packages simultaneously (I know, it's no way to run a railroad). So here's my thought. Each development team owns their own package, and thus their own subtree of the source directory. During the day, their compiled .class files might be messy or inaccurate, but hopefully everybody is clean at the end of the day, and the nightly build would compile everything and bundle each package into its own .jar file. Then the next day, each team is still developing using their own .class files, but they are pulling classes from OTHER packages from the stable .jar file. In order for this to work, however, I need to be able to specify options in my <javac> task which send the compiled classes to classes/for/my/package and pulls any necessary supporting classes from otherpackage.jar. However, if the value of my 'destdir' target is ALWAYS first in my $CLASSPATH, then I won't be compiling against the stable classes in otherpackage,jar; I'll be compiliing against the unreliable .class files in classes/for/another/package. Any ideas? Is the shared development idea I have hopeless in any event? Thanks, --dave
