Jon Stevens wrote: > > > adding to my classpath is being friendly, overriding it > > silently is not. > > I agree.
If I don't hear anything shortly, I will check in the change with having the system class path before the build's class path being the default. If anyone objects after that point, changing the defaut is easy enough... > One suggestion, add full dates to the output. In other > words, I want to know time and date when things were built. I figured it was more important to know when the code was last updated or checked out than when it was built. Click on the "Project: cvs" link at the top of any build log and you will see exactly when the code was checked out and what files were updated. The build time is already listed on the top index.html page. I'll add the date to the banner. > > 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. As near as I can tell, cocoon2 does not depend on turbine. > Other than above, it looks great! I want it! :-) I'll recommend waiting until the code settles down. - Sam Ruby Jon Stevens <[EMAIL PROTECTED]> on 12/27/2000 12:46:18 PM Please respond to [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> cc: Subject: Re: build.classpath and tinderbox builds 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
