I'm making available here a set of Ant build files that I often use to incorporate metrics into a project. More information about each library can be found in the resources section below. And for something more ambitious, have a look at Panopticode.
To get started, you will need to download Emma, JDepend and Simian (links below), and place the relevant jar files in your ANT_HOME/lib directory. (Note that there are restrictions on the use of Simian. Be sure to read the licensing information.) Next download the collection of build files. Unzip the archive anywhere you wish on your system.
You will find an example build file within the distribution (example/metrics-build.xml) that can be copied to any project directory. Then you can simply modify the file as necessary, and execute the collection of metrics by typing ant -f metrics-build.xml. That's it!
Why Emma? It goes without saying that developers should know what is not covered by their tests. This is clearly valuable information. It is equally clear that managers should not put arbitrary limits on coverage; some code may not need to be covered, and that's fine. Emma provides an informative report that can allow developers and their managers to intelligently explore what is not covered, and consequently make good decisions about where more attention is needed. In heavily regulated environments it is also necessary to demonstrate that one has a principled and clearly defined approach to managing test coverage, and in my experience Emma provides an excellent way to present an organization's testing rationale to auditors.
Why JDepend? Is there ever a good reason for cyclic dependencies among packages? I've never encountered an instance in which the simplest, clearest, and most robust design required the presence of a cycle. Even if there are good examples, they are surely rare and depending on the environment, might require some explanation. JDepend is the best tool available for identifying cycles and every project should use it.
Why Simian? Good software is not easily defined, but it is uncontroversial to suggest that large numbers of replicated blocks of code are not part of the definition. And it is equally uncontroversial to say that good software can turn into lousy software very quickly — especially when the team is large, with a broad spectrum of skill levels. Things can deteriorate very quickly when developers start cutting-and-pasting. Simian is invaluable for exposing this sort of behavior early, before it turns into a system-killer.