is a single-purpose tool for ContinuousIntegration
is more feature rich and has more far reaching goals.
A bit much here isn't it? How about CruiseControl is focused on ContinuousIntegration and says YAGNI for the rest of it. Better to integrate with Maven and Gump than to re-write it
is able to handle multiple projects and their dependencies (like Gump); CruiseControl
currently has limited multiple project support (single-threaded queue)
is administrated from a web application.
is typically administrated by modifying the config.xml which is typically stored in the source control system and is bootstrapped on each build. There is also a JMX web interface.
Both separate the notions of build and publish.
Both allow forced builds.
does this from the JMX interface.
I found AntHill
easier to debug and anthill people are very responsive.
I don't agree. I've installed and run both and found little difference in either of the above statements. CruiseControl was easy to setup (well as easy as Ant :) ) and the CC guys are just as helpful and solved my small number of setup problems very quickly. I switched from Anthill to CruiseControl in the end because CruiseControl is far more adaptable and does not force you to run under a web server. I really did not need or want Tomcat.
I prefer AntHill
scheduled builds versus CruiseControl
continuous builds because
continuity here tends to flood developers mail boxes with build failure
messages (especially for JUnit execution). I think it's more convenient to
know that you build is scheduled nightly rather than for each change you
submit to repository and in case you want to run an integration after having
submitted a change, you can still force a build.
I prefer the opposite. CC is not our build tool, it is a fire-and-forget system to notify us when something 'bad' gets checked in. -- Jtf
Surely the point of ContinuousIntegration is to train developers to only check in when it won't break the build? Is changing your process so developers are not bothered by a build break not precisely the wrong approach?
The expectation is that they will run the build/test locally first and that breaks will be rare. The most common cause for a build failure is that someone forgot to check-in a file and it is great to find out about that ASAP so it can be fixed ASAP. -- Jtf
supports both ContinuousModificationBasedBuilds?
It seems to me that the Continuous vs Scheduled debates are more a view of the tools' culture than capabilities. CruiseControl
's 'continuous' integration approach polls the source repository based on a configurable rate, usually every few minutes. Anthill's schedules work by polling the source repository for changes based on a configurable rate, defaulting to an hour. They work the same way with different defaults. Am I missing something?
build scheduler runs as a separate process which means a more complex integration on Windows as it requires a service wrapper (e.g. JavaService?
) to be run without a user logged in. AntHill
uses a thread run from servlet engine context, so it does not require to be wrapped as a Windows service and it uses one single JVM. I can imagine that this point can be looked at a disadvantage on a heavy loaded build machines. Ideally, both mechanisms are
useful and should be provided.
CruiseControl _is_ the build scheduler. Would be more accurate to say that CC's (optional) .jsp interface is read-only. -- Jtf
bills itself as a toolkit and this is what I found and what I really needed. Like Ant its uses plugins that I use to extend CC -- TC
''Hey! whats the difference - JavaService?
or Tomcat?? Both CC and Anthill need a service host to run unattended -- TC
uses XSL to present build log files, while it may look a good idea it
turned out to be a nightmare. Large XSL files are difficult to maintain and
forces a layout, so if you're not happy with the layout, you have to be prepared to a difficult work. We found that developers prefer to get raw log files than a nicer presentation that need to be maintained and may hide
important details in some cases.
I'm no fan at all of XSL but we've found it rather easy to create our own XSL files and mix them in with the ones that are already supplied. There's also the advantage that if you choose to use the HTMLEmailPublisher it reuses the same XSL files, or different ones if you'd like different information in your emails. Also on rereading this I realize that this is a pre-CC 2.0 comment. In 2.0 the XSL file has been split into several smaller files making customization much easier. -- Jtf
At some point, I'd like to see some experimentation with other technologies to generate the presentation (i.e., Velocity).
"Anthill rocks. Its far far easier to configure than Cruisecontrol and runs entirely as web application within a lightweight container like Tomcat." : - ErikHatcher
co-author Java Development with Ant http://email@example.com/msg22375.html
"In the Java world, there are a couple of contenders for CI frameworks, CruiseControl and Anthill. I reckon CruiseControl is a far superior product, and here I want to outline why."
: - MikeMason http://mikemason.ca/2004/08/12/
One of the reasons I picked Anthill over CruiseControl
was that CC wants everything right in the build.xml file. That seemed rather bizarre to me, and Anthill's clean separation from Ant seemed like the "right" solution. I wanted a build tool that would behave the way a developer would, using CVS and Ant separately (we access CVS using external CVS clients).
This comment seems outdated since the release of CC 2.0 a few months ago. -- Jtf
To be more specific, CC2 allows the build process to "bootstrap" by checking out from source control an ant build file that does the update from source control. In this way, the source control update is separated from the actual build script.
In fact you can update the entire project from cvs hence remove any cvs concerns from the build script. -- Ndl
requires a web server; CruiseControl
Link to c2.com/w4/cc/ deleted, because it's filled with wiki spam.
Pro costs $$ . Does Pro gives you features that are worth it?