ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Wood <>
Subject Re: build.classpath and tinderbox builds
Date Wed, 27 Dec 2000 13:50:41 GMT
I agree. I even debated about locally disabling it.

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.
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message