FuseMetrics starts with a config file - fusemetrics_config.xml (by default). This file is meant to give FuseMetrics all the information it needs to run - the directory trees where metrics .xml files are located, where the output goes, where the dashboard template is, which tools you want to run, and which graphs and histograms you want to make.

Note: FuseMetrics will recurse through subdirectories - you don't have to do anything special to make that happen.

General Rule

A) every <metric> entry in the config file that includes an analysis="..." attribute will analyze the metric data and create a sparkline graph of the appropriate metric.

B) every <metric> entry that includes a histogram="..." attribute will create a histogram based on the specified array of data.

C) If your metrics data files do not follow the default naming convention, the regexp="..." attribute on your <metric> records will allow you to vary that, using standard regular expressions

D) If some of your metrics are in different directory trees, use the filepath="..." attribute to specify, on a <metric> by <metric> basis where they can be found. If you don't specify a filepath, it defaults to the "global" filepath, as defined in fusemetrics_config.xml

Lastly, your dashboard.tmpl (or whatever your template file is) will be automatically converted into an html file by Groovy. You specify in the template which metrics and which images you'd like to include. Look at the big_sample directory for inspiration

A) Each type of analysis is managed via a tool-specific plugin. This allows us to add new tools easily, allows us to update tools easily, and allows us to have competing tools installed in parallel. This means that if you can't find a plugin to do what you want, you're free to build one.

B) FuseMetrics automatically creates a persistence area to store metrics over time, so you don't have to

A) The Histogram plugins don't do any analysis - they just provide structure for the creation of a histogram graph for a specified dataset. All the actual analysis occurs in the AnalysisPlugin

B) The Analysis plugins can, in some cases, overwrite each other's information - for example, multiple plugins generate the LOC metric. Sometimes this is a good thing... By convention, each plugin produces both the generic name (LOC), and a more plugin-specific name (checkstyle_LOC). Use a more plugin-specific name if you need to deal with collisions

• If you pass -d to FuseMetrics when you launch it, you'll see a data dump of every name in the namespace, and the corresponding value or array of values. Use this to help you build your template file properly.
• The metrics are processed in the order you enter the <metrics> records in the config file, so if you need certain files to run before others, that's the easiest way.

If you download the source, you'll find the doc/example/ directory contains one or more example projects, with a properly configured fusemetrics_config.xml and dashboard.tmpl for you to mimic/copy/convert.

Also, the etc/ directory contains a number of examples and samples used internally for unit testing

Here is an example fusemetrics_config.xml file

Here is an example dashboard.tmpl

• It would be nice to store histogram data over time so one could have a way to see changes in populations over time.
• Some would like the app to be more active - where you could filter and view histograms and sparklines of subsets of the overall project
• More Plugins
• Non-Java support - there's no technical reason why this couldn't be used to process metrics reports for other languages and systems. Also, there's no intrinsic need for the data to be in .xml formats.

Click the Contact Us link at the top of the page, and let us know how we can help.