The following (edited) thread from cruisecontrol-devel covers this topic. Feel free to refactor/summarize it.

Matt:

I have created and plugged in my own Builder. It succesfully (and silently) builds my project, returning only <build/>. At this point, I suppose I'm left with some options re: reporting.

#. build the (Ant?) XML that the Reporting JSP expects.
#. build my own XML and write some XSL to transform it on the Reporting JSP.
#. write static HTML and include it in the Reporting JSP.

I must say that I prefer #3 over #2, but neither option leverages the existing Cruise Control JSP XSL the way #1 does. On the other hand, #1 will likely require more effort than #3, initially.

What do you all think? Should I diverge and create my own front-end (#3), or is #1 my best bet? If #1 is better, could somene on the list provide me with a sample log*.xml that is reasonably comprehensive?

Jeff:

The best option really depends on your build system and how close it is to a "normal" build. If there is a lot of specialized lingo or data you want to report then your best bet is option 2. Take a look at MavenBuilder and maven.xsl to see an example of this. Note that CC does require that your xml start w/a build element and that you have an error attribute if the build failed. Other than that you can go to town. (header.xsl wants the time attribute as well)

If there's not a lot of special stuff you want to report, option 1 is pretty easy. The relevant bits of the ant log look like:

<build error="message text but only if build failed" time="1 hour 40 minutes 23 seconds">
  <target name="ignored" time="ignored">
    <task location="ignored" name="javac" time="ignored">
      <message priority="warn"><![CDATA[preformatted compiler warning messages]]></message>
      <message priority="error"><![CDATA[preformatted compiler error messages]]></message>
    </task>
    <task location="ignored" name="jar" time="ignored">
      <message priority="info"><![CDATA[message w/name of jar or war file]]></message>
    </task>
  </target>
</build>

header.xsl will use the error & time attributes on build element.

compile.xsl will look for the warn and error level messages inside a task named javac (or ejbjar) that is inside a target that is inside the build element. No harm in omitting these if you choose and writing your own xsl to get them from your own custom structure.

distributable.xsl will look for the info level messages that are inside a task named jar (or war) that is inside a target that is inside the build element. Again, no harm in omitting them.

javadoc: javadoc.xsl is just like the compile.xsl except the taskname is javadoc instead of javac.

merging XML output: you don't need to merge in xml file yourself, you can/should use the merge
element inside the log element to specify xml files to merge. http://cruisecontrol.sourceforge.net/main/configxml.html#merge

checkstyle: like unittest, checkstyle works off of an xml file that you merge in.