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

Reply via email to