ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <>
Subject build.classpath and tinderbox builds
Date Tue, 26 Dec 2000 22:29:19 GMT
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

For an example of why this is important to me, take a look at :

I'm attempting to build each project using the latest results from all the
projects that they depend on.  If you notice the xml-cocoon build failed,
and it looks like there are recent changes to both the xml-fop and turbine
projects which will likely break cocoon if they are released in their
current form.  You may also notice that the xml-cocoon2 build did *not*
fail - this is because the xml-cocoon2 build process overrides the
classpath I provided; I have verified that at least the xml-fop changes
will break xml-cocoon2.

Suggestions for property names, values, alternate approaches, or comments
on the tinderbox builds I am prototyping are all welcome.

- Sam Ruby

View raw message