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 : > > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
