Thanks for the tip. Cheers,
Peter. ----- Original message ----- > > On Apr 23, 2014, at 8:01 AM, Peter <j...@zeus.net.au> wrote: > > > ----- Original message ----- > > > > > > On Apr 22, 2014, at 7:47 PM, Peter Firmstone > > > <peter.firmst...@zeus.net.au> wrote: > > > > > > > > > > > > > > > From: Peter Firmstone <peter.firmst...@zeus.net.au> > > > > Subject: Decision process for a Modular build tool > > > > Date: April 22, 2014 at 7:40:29 PM EDT > > > > To: d...@apache.river.org > > > > Reply-To: Peter Firmstone <peter.firmst...@zeus.net.au> > > > > > > > > > > > > I started qa-refactor with the intent of fixing latent bugs, an > > > > unintentional benefit is significantly reduced processing times, > > > > contention and increased scalability. > > > > > > > > Changes in timing exposed more bugs. > > > > > > > > Up until recently an occassional build failure would be experienced > > > > due to classdep only partially writing a dep file, resulting in > > > > ClassNotFoundException during testing. Knowing that > > > > RFC3986URLClassLoader is much faster resolving classes than > > > > URLClassLoader, I thought, I'd try using it in ClassDep. > > > > > > > > Guess what the result was? That's right lot's more > > > > ClassNotFoundException's > > > > > > > > > > > > > > That seems kind of odd. Since ClassDep is single-threaded (it’s > > > basically a command line utility after all), how would faster class > > > path resolution have any impact on the output file? > > > > Ok, fair call, ClassDep has a bug, I'm not sure of the exact cause. > > I would suggest just adding a call to System.out.flush() at the end of > main() and even System.out.close() just because you may be using a > broken library that is not successfully flushing and closing. Look at > the size of the files that are output. Are they multiples of some power > of 2 that would be like a block write size? That would indicate that > blocks are being written as a blocks worth of output is created. > > Gregg Wonderly >
