You're having trouble ConfiguringCruiseControl and there doesn't seem to be enough information output to the console to tell you what the problem is.
Turn on Debug
CruiseControl uses log4j as its logging library, whose logging verbosity can be tuned both modifying its configuration and dynamically.
Persistent changes
These changes require restarting CruiseControl (or at least its build loop).
Modify log4j configuration
To do this edit your log4j.properties file (or override using CLASSPATH precedence) and change the first line from:
to:
This will increase the amount of information printed to both the console and cruisecontrol.log
Note that this may have the side-effect of dramatically inscreasing the size of your log file depending on your setting for the UseLogger attribute.
use -debug
Starting from CruiseControl 2.2, you can pass the -debug argument (or UseDebug attribute) to your cruisecontrol build loop script (or cruisecontrol & jetty script).
This will automatically override the default Category Level to DEBUG.
Note that this setting can only be used if UseLogger is set to true.
Temporary change
This properties-stuff is annoying, I just want to turn on debug temporarily and don't want to edit files and restart CruiseControl
In versions later than 2.1.6, you can use the JMX interface to set the logging level used by the root logger (See Managing CruiseControl With JMX).
In the HTML interface, click the link that says "Logger:name=root". In the LoggingLevel entry field, just enter 'debug' (without the quotes) as the logging level and click 'set' to turn on debug and enter 'info' to return to the default level. This setting will be remembered as long as CruiseControl keeps running. If you restart, the setting will be reset to the value in log4j.properties, which is INFO by default.
Notes & Questions
The latest version of CruiseControl also has a useDebug attribute for the AntBuilder which will pass -debug -verbose to Ant. Previously that would only happen if the log4j level was set to DEBUG. The idea is that now those two are decoupled. If you have useLogger=false you should be able to see the difference in output between useDebug=true and useDebug=false.
Which log4j.properties file - the one from CruiseControl?
The log4j.properties in the cruisecontrol.jar. If you are rebuilding cruisecontrol you can edit the log4j.properties in cruisecontrol/main as this file will be included in your jar when you rebuild.
Better way: create your own log4j.properties and ensure it's ahead in the CLASSPATH.
"Create your own log4j.properties and ensure it's ahead in the CLASSPATH" - sorry, where do I create that and what do you mean by 'ahead'. Also, where is my class path set?
I think what this means is this: create a modified version of log4j.properties, and put it in some directory - any old place you like. Then, run CruiseControl with a class-path that mentions this directory before the cruisecontrol.jar file.
But note that this is a little more difficult than it sounds, if you are used to running using the "-jar" flag:
The beauty of this form is that you don't have to specify the class path - it's specified for you inside the jar file. But to run with a separate (modified) log4j.properties file, you would have to do something like this (assuming Unix style):
where "mydir" is the place where you ended up putting your modified log4j.properties, and "(etc)" continues a long list of library jar files that are needed to run CruiseControl. (The list of needed jar files can be found in the "main/manifest.mf" file of the distribution.)
Gee, modifying CruiseControl's own log4j.properties file and rebuilding CruiseControl suddenly sounds a lot more appealing.
You can also tell Log4J where the properties file is via a system property setting, which is extremely easy to do
See also GenericDebuggingHelp
