Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 14167 invoked from network); 28 Dec 2000 01:56:52 -0000 Received: from repulse.concentric.net (HELO repulse.cnchost.com) (207.155.248.4) by h29.sny.collab.net with SMTP; 28 Dec 2000 01:56:52 -0000 Received: from [192.168.0.2] (w005.z208176150.sjc-ca.dsl.cnc.net [208.176.150.5]) by repulse.cnchost.com id UAA06630; Wed, 27 Dec 2000 20:56:51 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Errors-To: User-Agent: Microsoft-Entourage/9.0.2509 Date: Wed, 27 Dec 2000 17:56:52 -0800 Subject: Re: build.classpath and tinderbox builds From: James Duncan Davidson To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: h29.sny.collab.net 1.6.2 0/1000/N On 12/26/00 2:29 PM, "Sam Ruby" wrote: > I'm contemplating making a change to ...taskdefs.javac.getCompileClasspath, > and would like to solicit feedback before making the change. At the > moment, the classpath attributes/elements are placed in *FRONT* of any > system defined classpaths. In most cases, this means that the developer > has no easy way to override this behavior at runtime. > > What I would like to do is to introduce a build.classpath property that > modifies this behavior. Depending on the value of this property, the > system class path is placed in front, in back, or is not overridden at all. > I'm willing to leave the default behavior as it is, though I disagree with > it - adding to my classpath is being friendly, overriding it silently is > not. Yes, overriding the classpath silently is a problem. It is pretty much how the javac command line works -- ie if you spec a classpath, it uses that instead of $CLASSPATH. I'm not sure what it does with bootclasspath stuff though. I'm not sure that I like the idea of having a flag set that alters behavior in a global way for all tasks -- it seems to me that you'd want to be careful about this on a task by task basis. I'd rather export out the currently in use classpath via a property or put a flag on the javac task that was something like 'ignoresystemclasspath="yes"' -- James Duncan Davidson duncan@x180.net !try; do()