qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Date Thu, 08 Mar 2007 13:03:55 GMT

I just want to bring this up....

Make sure you send a note to infrastructure@a.o 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.


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 <aconway@redhat.com> 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
P: 781-902-8727    C: 508-380-7194

View raw message