Robert, I've seen your comment on JavaNCSS. Thanks for sharing the info. I was wondering if you had tried JDepend. I described it a little bit in a former post on the same thread.
I am currently using this tool in my Ant builds, hoping like you to find a way to analyse the results one day :)) Perhaps will you find it interesting. Cheers Jerome > -----Original Message----- > From: Robert J. Clark [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 13, 2001 1:19 AM > To: [EMAIL PROTECTED] > Subject: Re: Need Ammo in Make vs. Ant argument... > > > On Tue, 12 Jun 2001 15:40:49 -0700 "Steve Loughran" > <[EMAIL PROTECTED]> wrote: > > > > ----- Original Message ----- > > From: "Robert J. Clark" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, June 11, 2001 15:24 > > Subject: Re: Need Ammo in Make vs. Ant argument... > > > > > > > On Sat, 9 Jun 2001 15:48:27 +1000 Tim Vernum > > <[EMAIL PROTECTED]> wrote: > > > > > > > From: Lance Hankins [mailto:[EMAIL PROTECTED] > > > > > > > > > Any ammunition will be greatly appreciated :) > > > > > > > > I can get you some research (that I think was from Sun) that showed > > > > that for a large system, 10% of the code was in the build process. > > > > > > I would also be interested in reading this if it is available. Drop > > > me a line offlist if you would like. > > > > > > > But any metric of a large in house development system should give > > > > similar results. > > > > > > This is what we are seeing here as well. > > > > I havent done a line by line count, but here we have 50KB of > build files and > > 457KB of java source. So that 10% metric still holds in ant > -but note that > > the build files cover web service installation and behind firewall > > deployment to multiple staging sites. Oh, and did I mention the > CD burn for > > the beyond firewall deployment? > > Yeah, a lot of our Ant code deals with packaging the builds (CD images > tar files and the like). The XML build files that actually build > the product > are now the minority. Most of the work is in packaging. > > > Actually this raises an interesting task idea: what do we have > in terms of > > source code metric tasks -like lines of code, #of statements, > #of branches, > > class and method counts, which could be auto extracted during a build > > process. If some analysis was always done as part of the build > process, it'd > > be an easy way to generate interesting data. > > We are currently experimenting with the same idea here. Source > code metrics > for the product are computed for each build. We are using a Java package > called JavaNCSS (http://www.kclee.com/clemens/java/javancss/). > The metrics that > it provides are fairly simple; Cyclomatic Complexity Number, Non > Commenting > Source Statements, and Number of Javadoc comments. The build system just > executes this as a <java></java> task as I have not gotten around > to writing > a task wrapper for the jar. > > Right now we have not done much in the way of using these > results, but they > do look promising. I am hoping someday to be able to hook up this > infomation > with our bug tracking system so the build system will be able to > tell what bugs > have been corrected by a specific build and also which parts of > the code generate > the most bug reports/fixes. > > So many ideas, so little time. That is one problem that I have > found with Ant > (dragging this back to topicallity). It is so easy to do almost > anything that > it is hard to step back and say "do I need to do this?" > > - Rob
