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? What exactly do you mean by “only partially writing a dep file”? Does it not get closed off? Are characters omitted? Do you have examples of the incomplete “del” files? The once or twice I’ve looked at it in the past, the classes in question were actually in the jar files on the class path, which wouldn’t seem to point to ClassDep. Is it possible that there’s a problem with the new ClassLoader (RFC3986URLClassLoader)? > Qa-refactor is stable, but only when the build process succeeds without > error. > > I now must choose, do I waste time fixing a legacy build tool, or is it time > for a modular build to reduce long term maintenance and simplify, lowering > the bar for new users? > > The question of modular builds is orthogonal to problems with either ClassDep or the new ClassLoader you’re talking about. It makes the most sense to get a solid diagnosis (and probably fix) for the problem as it has presented itself, rather than diving into a new source code layout. Not to mention that there may actually be users of ClassDepAndJar, apart from the River build. Cheers, Greg Trasuk. > To me, going modular is a no brainer, but what tool should we use and why? > > * Maven > * Gradle > * Ivy & ant > > Please keep responses to the point, with any pro's and cons you have, eg: > > Maven: > +widely adopted > +well structured dependency relationships > -dependency downloads. > > Gradle: > -adoption > +Groovy build scripts > > Ivy: > +uses ant, our existing build tool > -adoption > > When complete, I suggest, we all can rank the relevance or importance of each > point raised (on a scale of -10 to 10) then add up for the final score to > decide the tool. > > Regards, > > Peter. > > >
