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 : http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.html. 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
