on 12/26/2000 2:29 PM, "Sam Ruby" <[EMAIL PROTECTED]> 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. I agree. > For an example of why this is important to me, take a look at : > > http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.ht ml> . > Nice layout. :-) One suggestion, add full dates to the output. In other words, I want to know time and date when things were built. FYI, I just used your tool to fix the javadoc and compiler warnings in Turbine. :-) > 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. The Turbine ones will as well if Cocoon2 is depending on the database pool. > Suggestions for property names, values, alternate approaches, or comments > on the tinderbox builds I am prototyping are all welcome. Other than above, it looks great! I want it! :-) -jon -- Honk if you love peace and quiet.
