This is interesting - I wasn't aware that Apache had hardware for supporting project specific continuous build environments (and I guess people to support it ) ?
On 3/8/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
I just want to bring this up.... Make sure you send a note to [EMAIL PROTECTED] as well as legal@ and possibly the incubator PMC's before making any final desision. There are several "free for use with open source projects" that we really shouldn't be using do to reverse-marketing stipulations that are unacceptable to apache, especially for incubator projects. Also, you should work with infra to get it hosted on apache hardware if at all possible. It would look much better from a project standpoint to be working with apache. Dan On Thursday 08 March 2007 03:55, Rupert Smith wrote: > Still, I think we should accept the AntHill licence because it is > without doubt a superior product. I need to chase them up about it, > but was hoping to some back to them with an enthusiastic response from > the qpid developers first. Accepting the licence doesn't commit us to > it forever, we can try it out and see if we are happy first. In fact, > download a free trial and try it out for yourself. > > CruiseControl is ok for building relatively simple Java projects. I > find it quite buggy, recently I moved my personal library onto svn > from cvs. CC would no longer invoke maven multiple times, only the > first maven call would ever execute... You get what you pay for I > suppose. > > Anthill offers two very usefull things, wrt to qpid, that cruise > control does not. A server/agent architecture, and the 'Build Life' > concept. > > The server/agent architecture, allows you to set up build agents on > many machines (each one a bit like an instance of Cruise Control). The > server farms the build jobs out to the agents. This is ideal for > coordinating a build accross Unix and Windows boxes. > > The build life concept puts all stages of a multi-agent or multi-step > build under a common version stamp that spans the life of the entire > process. This means that the build server is clever enough to know > that the parts it built and tested on different boxes all belong to > the same build life. So you can build accross multiple os, test > accross multiple os, perhaps tck validate, and have a consistent build > stamp over all of this. If a build makes it through the entire > process, all build artifacts can be promoted, in step with each other. > > On 3/8/07, Alan Conway <[EMAIL PROTECTED]> wrote: > > Nuno Santos wrote: > > > Will also need to check regarding the licensing issue... our plan > > > was to use CruiseControl but I see in the chart that you mentioned > > > -- very useful, btw -- that it doesn't directly support "make", so > > > we have to see if we can somehow integrate the C++ build with > > > CruiseControl, or opt for a different continuous build tool. > > > > I've participated in large scale multi-project mixed C++/Java builds > > in cruisecontrol before, it'll do the job with a bit of custom > > scripting. It's easy to do make, just write an ant script that calls > > make. There are (were) xslt scripts shipped with cruisecontrol that > > turn the stdout and stderr from make into a nice HTML log with the > > stderr bits highlighted in red. You can also get CppUnit results > > nicely formatted as HTML by hacking the cruisecontrol xslt for JUnit > > logs. > > > > The other tools may still be worth investigating, I've no experience > > with them. > > > > Cheers, > > Alan. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
