This is a list of important features needed to make CruiseControl an enterprise-grade development tool. Please only add quality-related tasks to this list; shiny stuff like dashboard and control panel features should be requested in the WishList.

If development of one of these features is underway, add a name and date next to it!

Make the CruiseControl JSP reporting module proxy-friendly. Currently the host name is hardcoded into every URL. They should be relative so that when the display is proxied by another server the links can be viewed.

Example: CruiseControl is running on IntraNet, but we need to share results with remote team over WWW. It's quick and easy to add a proxy configuration to our Apache HTTPD project server--but external people can't follow any links because they all point to the internal server.

fix the Web reporting component to allow it to run in a headless environment. (No GUI display).
See http://jira.public.thoughtworks.org/browse/CC-4

external api-communication over HTTP - perhaps XML via something like SOAP or JAX-RPC

Aslak Hellesøy defined a project for creating a generalized API for continuous integration systems like CruiseControl: FBI. They seem to be changing to SOAP after starting out with JAX-RPC. When they've come up with a somewhat stable API, we should try to adhere to it.

NOTE: the link above leads to a project on SourceForge that describes itself "FBI - Friends' Buddies Integrator. Try to construct a RSS like standard to describe one person's public relationship network". Propably not the right FBI... Is the "Funky Build Integration" -project still alive somewhere?

overhaul of the config.xml-file to make it easier to define stuff that is not specific to one project, like plugins, email-mappings, etc

Still a lot to do, but plugins can now be defined globally (i.e. outside of <project>s, directly under <cruisecontrol>)

Adding a project requires CC to restart: fix that!
Being fixed: http://jira.public.thoughtworks.org/browse/CC-161

log-files are treated as Dom-trees completely in memory, most of the information could just as easily be obtained using SAX (including XSLT-transformations), which would save people with large log-files a lot of headaches solving out-of-memory errors

Still a lot to do. SAX XMLFilters are now used for pruning <property> tags from JUnit result logs and for getting rid of empty <task> and <message> tags generated by Ant's XmlLogger

generic infrastructure that supports monitoring and configuring and controlling CC via an external process

Hopefully, this can partly be achieved by clients that adhere to the API defined by FBI.

use custom tags in config.xml releated classes to describe config.xml elements; create a Doclet that generates config.xml html documentation automatically from source