ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <>
Subject Re: build.classpath and tinderbox builds
Date Thu, 28 Dec 2000 01:56:52 GMT
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

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                              
                                                                  !try; do()

View raw message