You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rupert Smith <ru...@googlemail.com> on 2007/03/06 17:26:41 UTC
Continuous Build Server. Was: NEED HELP: getting the trunk back in order
I have tried out a few different build servers. I started by looking
at this feature matrix (probably not entirely complete or up to date):
http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix
As you can see there are two that have more green ticks than the
others. Anthill Pro and Viewtier Parabuild. I tried both. Anthill Pro
looks very good (maven build running on my machine, configured in 18
minutes!). Parabuild looked pretty awfull.
Anthill Pro have offered to give us a free licence as they do this for
open source projects. The Apache Geronimo project has already set the
precedent by also using Anthill Pro 3. They've had their own debate,
around the subject of wether or not they should be using non-free,
non-open source software and whether or not using it will force people
building from a checkout to also use it. Read the debate here:
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200612.mbox/ajax/%3c18073DCE-7011-41D0-877F-45DD8F8CA1B8@planet57.com%3e
To summarize:
It won't force people to be dependant on anthill, because the build
server and build system are seperate things. The build system is
maven, make, msbuild etc. All anthill does is call it periodically to
do the build. The build system will still need to be maintained and
kept in working order for every day devlopment activity from the
command line.
As for non-free, non-os software. We already use Jira, Confluence, not
to mention MsBuild and Visual Studio, which kind of takes the moral
argument out of that point of view.
I'd like to propose that we accept Urban Code's kind offer of a free
licence. Their product is the only one which can do a fully automated
build over multiple languages and operating systems, call our test
scripts and collate the results.
Rupert
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Rupert Smith <ru...@googlemail.com>.
Yup, ideally on a machine that all committers have (secure) access to,
can provide web interface to the anthill web console, and can spam us
with broken build emails. Until then, we'll just have to experiment
with a machine behind the firewall. We are not in a position to
provide a machine open to the outside world for this, nor are we
allowed to do email spamming.
As an interim solution, I might look into seeing if I can automate the
upload of builds reports onto the wiki. I think email spamming is of
limited use anyway.
Rupert
On 3/8/07, Martin Ritchie <ri...@apache.org> wrote:
> Does apache have windows build machines. We really need to build on
> windows (.net) and RHEL 3 & 4 for c++ as well as java. Then interop
> test the result. The guys from AntHillPro have said we can have a
> licence we just need to sort out how/where we use it.
>
> On 08/03/07, Daniel Kulp <da...@iona.com> wrote:
> > On Thursday 08 March 2007 09:13, Marnie McCormack wrote:
> > > 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 ) ?
> >
> > There is a continuum vm setup that several java projects are using:
> >
> > http://vmbuild.apache.org/continuum/servlet/continuum
> >
> > Unfortunately, it's not exactly a fast machine. Also, your java builds are
> > not continuum compatible.
> >
> >
> > TLP's can also ask for a zone to be created on zones. However, I'm not
> > sure if a podling can or not. The "rules" say your PMC chair is the
> > administrator for the zone, but the podlings official PMC chair is the
> > incubator PMC chair. Thus, I'm not sure if podlings are allowed or not.
> > If you're interested, you could ask and see what they say.
> >
> > Dan
> >
> >
> > >
> > > On 3/8/07, Daniel Kulp <da...@iona.com> wrote:
> > > > 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.
> > > >
> > > > 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 <ac...@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
> > > > IONA
> > > > P: 781-902-8727 C: 508-380-7194
> > > > daniel.kulp@iona.com
> > > > http://www.dankulp.com/blog
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727 C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
> >
>
>
> --
> Martin Ritchie
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Robert Godfrey <ro...@gmail.com>.
The only issue is the credit which AntHill may/may not require and where it
needs to be placed. If it is on an apache web site then we need some sort
of official OK. If this is a requirement of the AntHill license then we
need the OK on this before we move from evaluation of AntHill to actual
use...
-- Rob
On 09/03/07, Rupert Smith <ru...@googlemail.com> wrote:
>
> On 3/9/07, Robert Godfrey <ro...@gmail.com> wrote:
> > 1. is AntHill offering a license for any of the contributors to run a
> > continuous build against the apache subversion project?
> > 2. is there any restriction on the number of continuous build systems
> thus
> > set up?
> > 3. if individual contributors / organisations take wish advantage of
> such a
> > license, is the qpid community as a whole happy to credit AntHill in the
> > manner required.
> > 4. finally even of the Qpid community is happy to credit AntHill, is
> Apache
> > happy to allow Qpid to do so
>
> The licence they gave us allows contributors pretty much free reign,
> so long as it is used to produce OS software only.
>
> No restriction on the number of systems. 999 users, 999 build agents.
>
> I'm assuming Apache is happy for us to use it, as I say, Geronimo have
> set the precedent already. Have not made any official enquiries
> towards Apache yet though.
>
> As you point out, the build server and build system are seperate.
> There is absolutely no need to check the AH config files into the
> source respository at all. Using it does not force anyone interested
> in using/building qpid to use AH.
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Rupert Smith <ru...@googlemail.com>.
On 3/9/07, Robert Godfrey <ro...@gmail.com> wrote:
> 1. is AntHill offering a license for any of the contributors to run a
> continuous build against the apache subversion project?
> 2. is there any restriction on the number of continuous build systems thus
> set up?
> 3. if individual contributors / organisations take wish advantage of such a
> license, is the qpid community as a whole happy to credit AntHill in the
> manner required.
> 4. finally even of the Qpid community is happy to credit AntHill, is Apache
> happy to allow Qpid to do so
The licence they gave us allows contributors pretty much free reign,
so long as it is used to produce OS software only.
No restriction on the number of systems. 999 users, 999 build agents.
I'm assuming Apache is happy for us to use it, as I say, Geronimo have
set the precedent already. Have not made any official enquiries
towards Apache yet though.
As you point out, the build server and build system are seperate.
There is absolutely no need to check the AH config files into the
source respository at all. Using it does not force anyone interested
in using/building qpid to use AH.
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Rupert Smith <ru...@googlemail.com>.
The distributed build is not to make it run faster.
It is so that the build process can build the c++ on a linux box, and
the .net build on a windows box. Both can be tied together under a
common build stamp. They can be interop tested (by calling scripts on
both boxes). If the tests pass, the build artifacts, under the common
stamp, can be promoted together as a succesfull build.
Its working out how to coordinate this process of building accross
multiple boxes that I see as being the difficult part of automating a
Qpid build. I had that in mind though, as I was writing the interop
testing spec, trying to imagine how I would be able to get that sort
of distributed testing to work.
In anthill I set up agents, on a windows box and on a linux box. I
then define a workflow that goes like this:
create new build stamp.
fork:
build cpp on linux agent: build java on linux agent: build dotnet on
windows agent.
join:
call broker start script on linux agent.
fork:
call startall test clients scripts on all agents.
join:
call coordinator start script on linux agent.
call broker stop script on linux agent.
publish the test results.
(maybe some more steps here, like tck testing).
if it all passed:
gather consistently stamped build artifacts from all agents (the
distributions).
On 3/9/07, Alan Conway <ac...@redhat.com> wrote:
> Rupert Smith wrote:
> > On 3/9/07, Alan Conway <ac...@redhat.com> wrote:
> >> distcc for make) not the continuous build system. "Native" make
> >> integration sounds nice but integration via ant is so straightforward
> >> that I can't imagine what additional value it provides.
> >
> > Well go ahead and write a distributed build system via ant then. Let
> > us know in a few months/years from now when it is ready.
> >
> Hah! Good one. I sortof assumed that there were tools already out there.
> Java compilers are so fast that I've never been on a project with enough
> source to need distributed builds. I wouldn't have thougt Qpid Java was
> that big/slow building but then my C++ background has acclimatized me to
> much longer build times.
>
> Anyway if we need distributed Java builds then that's a big plus for
> AntHill.
> > As I say, I got the maven build system hooked up through AH in 18
> > minutes of configuration effort, cpp now hooked up in about 45
> > minutes, not done the dotnet yet but as its just a single
> > build-dotnet20 script call, I'm getting better at it so I don't think
> > it'll take too long.
> That's pretty good - I spentlonger than that getting CruiseControl to do
> C++. What do the build/test results look like? Any
> highlighting/linking/other fanciness or just a big splurge of stdout? We
> can make the CppUnit tests barf XML, does AH support CppUnit directly?
> If not a bit of xslt will probably do the trick - that's what I did with
> CruiseControl to get nice formatted test result pages like JUnit.
>
> Cheers,
> Alan.
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back
in order
Posted by Alan Conway <ac...@redhat.com>.
Rupert Smith wrote:
> On 3/9/07, Alan Conway <ac...@redhat.com> wrote:
>> distcc for make) not the continuous build system. "Native" make
>> integration sounds nice but integration via ant is so straightforward
>> that I can't imagine what additional value it provides.
>
> Well go ahead and write a distributed build system via ant then. Let
> us know in a few months/years from now when it is ready.
>
Hah! Good one. I sortof assumed that there were tools already out there.
Java compilers are so fast that I've never been on a project with enough
source to need distributed builds. I wouldn't have thougt Qpid Java was
that big/slow building but then my C++ background has acclimatized me to
much longer build times.
Anyway if we need distributed Java builds then that's a big plus for
AntHill.
> As I say, I got the maven build system hooked up through AH in 18
> minutes of configuration effort, cpp now hooked up in about 45
> minutes, not done the dotnet yet but as its just a single
> build-dotnet20 script call, I'm getting better at it so I don't think
> it'll take too long.
That's pretty good - I spentlonger than that getting CruiseControl to do
C++. What do the build/test results look like? Any
highlighting/linking/other fanciness or just a big splurge of stdout? We
can make the CppUnit tests barf XML, does AH support CppUnit directly?
If not a bit of xslt will probably do the trick - that's what I did with
CruiseControl to get nice formatted test result pages like JUnit.
Cheers,
Alan.
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Rupert Smith <ru...@googlemail.com>.
On 3/9/07, Alan Conway <ac...@redhat.com> wrote:
> distcc for make) not the continuous build system. "Native" make
> integration sounds nice but integration via ant is so straightforward
> that I can't imagine what additional value it provides.
Well go ahead and write a distributed build system via ant then. Let
us know in a few months/years from now when it is ready.
As I say, I got the maven build system hooked up through AH in 18
minutes of configuration effort, cpp now hooked up in about 45
minutes, not done the dotnet yet but as its just a single
build-dotnet20 script call, I'm getting better at it so I don't think
it'll take too long.
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back
in order
Posted by Alan Conway <ac...@redhat.com>.
Robert Godfrey wrote:
> Is the continuous build set up part of the project though? That is,
> even if
> we use AntHillPro (or any other solution) for our own continuous build...
> there's nothing stopping anyone else setting up their own continous build
> using any technology they like. (Although if they do so can I strongly
> request them not to spam the qpid-dev list with the results :-) ).
I believe it should be. There's nothing stopping people from
independently writing
any number of continuous build systems but thats all wasted effort that
could
instead be put into building one really good shared system, or into
doing Qpid development.
> 1. is AntHill offering a license for any of the contributors to run a
> continuous build against the apache subversion project?
> 2. is there any restriction on the number of continuous build systems
> thus
> set up?
> 3. if individual contributors / organisations take wish advantage of
> such a
> license, is the qpid community as a whole happy to credit AntHill in the
> manner required.
> 4. finally even of the Qpid community is happy to credit AntHill, is
> Apache
> happy to allow Qpid to do so
>
I think we're of a similar opinion except that I feel that anyone with
an interest in Qpid, not just the comitters, should be able to use and
contribute to the continuous build system just like any other part of
the project.
From the matrix it looks like it has a stronger web interface that
CruiseControl. Distributed builds is a red herring IMO. Build
distribution should be done by the developer build system (e.g. using
distcc for make) not the continuous build system. "Native" make
integration sounds nice but integration via ant is so straightforward
that I can't imagine what additional value it provides.
If the license allows anyone to use & contribute to the Qpid continuous
build system, for purposes of testing Qpid only, then those advantages
make AntHill worth considering . If its only for use by all contributors
(present and future) then I'd be reluctant but might be open to
persuasion if AntHill turns out to be really cool. If the license
restricts us to a limited number of hosts, specific named companies or
the like then I'm dead against it.
Cheers,
Alan.
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Robert Godfrey <ro...@gmail.com>.
Is the continuous build set up part of the project though? That is, even if
we use AntHillPro (or any other solution) for our own continuous build...
there's nothing stopping anyone else setting up their own continous build
using any technology they like. (Although if they do so can I strongly
request them not to spam the qpid-dev list with the results :-) ).
As I see it, RedHat are looking to set up a continuous build machine inside
that organisation in order to help their developers, and they are further
volunteering to mail out the results to the list. Other contributors are
also interested in setting up a continuous build environment to help their
developers, but they would not be able to mail the list with results.
Further, while Red Hat is obviously most focused on test results on Linux,
other contributors will be requiring Qpid to run correctly on alternative
operating systems (not limited to Windows). Some of our clients may only be
able to build correctly on some platforms.
For me the licensing questions are these:
1. is AntHill offering a license for any of the contributors to run a
continuous build against the apache subversion project?
2. is there any restriction on the number of continuous build systems thus
set up?
3. if individual contributors / organisations take wish advantage of such a
license, is the qpid community as a whole happy to credit AntHill in the
manner required.
4. finally even of the Qpid community is happy to credit AntHill, is Apache
happy to allow Qpid to do so
One point for clarification:
Looking at AntHill's pricing model they use committer to a repository as
their way of measuring users. I'm extrapolating from this to assume that
they would thus be granting a license to build against the apache subversion
repository. This would (I assume) not cover any development work on other
repositories that people may be doing (for instance the people working on a
BDB based store plugin).
-- Rob
On 09/03/07, Alan Conway <ac...@redhat.com> wrote:
>
> Martin Ritchie wrote:
> > Does apache have windows build machines. We really need to build on
> > windows (.net) and RHEL 3 & 4 for c++ as well as java. Then interop
> > test the result. The guys from AntHillPro have said we can have a
> > licence we just need to sort out how/where we use it.
> >
> I'm wary about the licencing We won't get apache or anyone else to offer
> available-to-all test hosts for every os/hardware combination that every
> contributor cares about - we already have JPMC wanting windows, Red Hat
> obviously need to test on RH linux etc. So anyone with an interest in
> qpid (which essentially means anyone at all) must be free to run the
> qpid continuous build system on any hardware/os they want and modify to
> their special needs it if they have to.
>
> If the AntHillPro license does not allow that then I'm strongly against
> using it. We will put a lot of effort into this harness to make it work
> well, I'd rather put a little more effort into a solution thats
> available to all (e.g. CruiseControl) than use an easier/slicker
> proprietary solution but end up with a fractured community and forked
> testing efforts because some parties can't use it due to licensing
> restrictions.
>
> Cheers,
> Alan.
>
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back
in order
Posted by Alan Conway <ac...@redhat.com>.
Martin Ritchie wrote:
> Does apache have windows build machines. We really need to build on
> windows (.net) and RHEL 3 & 4 for c++ as well as java. Then interop
> test the result. The guys from AntHillPro have said we can have a
> licence we just need to sort out how/where we use it.
>
I'm wary about the licencing We won't get apache or anyone else to offer
available-to-all test hosts for every os/hardware combination that every
contributor cares about - we already have JPMC wanting windows, Red Hat
obviously need to test on RH linux etc. So anyone with an interest in
qpid (which essentially means anyone at all) must be free to run the
qpid continuous build system on any hardware/os they want and modify to
their special needs it if they have to.
If the AntHillPro license does not allow that then I'm strongly against
using it. We will put a lot of effort into this harness to make it work
well, I'd rather put a little more effort into a solution thats
available to all (e.g. CruiseControl) than use an easier/slicker
proprietary solution but end up with a fractured community and forked
testing efforts because some parties can't use it due to licensing
restrictions.
Cheers,
Alan.
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Martin Ritchie <ri...@apache.org>.
Does apache have windows build machines. We really need to build on
windows (.net) and RHEL 3 & 4 for c++ as well as java. Then interop
test the result. The guys from AntHillPro have said we can have a
licence we just need to sort out how/where we use it.
On 08/03/07, Daniel Kulp <da...@iona.com> wrote:
> On Thursday 08 March 2007 09:13, Marnie McCormack wrote:
> > 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 ) ?
>
> There is a continuum vm setup that several java projects are using:
>
> http://vmbuild.apache.org/continuum/servlet/continuum
>
> Unfortunately, it's not exactly a fast machine. Also, your java builds are
> not continuum compatible.
>
>
> TLP's can also ask for a zone to be created on zones. However, I'm not
> sure if a podling can or not. The "rules" say your PMC chair is the
> administrator for the zone, but the podlings official PMC chair is the
> incubator PMC chair. Thus, I'm not sure if podlings are allowed or not.
> If you're interested, you could ask and see what they say.
>
> Dan
>
>
> >
> > On 3/8/07, Daniel Kulp <da...@iona.com> wrote:
> > > 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.
> > >
> > > 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 <ac...@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
> > > IONA
> > > P: 781-902-8727 C: 508-380-7194
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
--
Martin Ritchie
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Daniel Kulp <da...@iona.com>.
On Thursday 08 March 2007 09:13, Marnie McCormack wrote:
> 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 ) ?
There is a continuum vm setup that several java projects are using:
http://vmbuild.apache.org/continuum/servlet/continuum
Unfortunately, it's not exactly a fast machine. Also, your java builds are
not continuum compatible.
TLP's can also ask for a zone to be created on zones. However, I'm not
sure if a podling can or not. The "rules" say your PMC chair is the
administrator for the zone, but the podlings official PMC chair is the
incubator PMC chair. Thus, I'm not sure if podlings are allowed or not.
If you're interested, you could ask and see what they say.
Dan
>
> On 3/8/07, Daniel Kulp <da...@iona.com> wrote:
> > 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.
> >
> > 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 <ac...@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
> > IONA
> > P: 781-902-8727 C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <da...@iona.com> wrote:
>
>
>
> 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.
>
> 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 <ac...@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
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Rupert Smith <ru...@googlemail.com>.
On 3/8/07, Daniel Kulp <da...@iona.com> wrote:
>
>
> 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.
I'm hoping that it will be acceptable for Apache, as Geronimo are
already using it.
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Daniel Kulp <da...@iona.com>.
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.
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 <ac...@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
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Rupert Smith <ru...@googlemail.com>.
I upgraded in the hope of fixing my problems with svn. It didn't solve
that problem but it did at least stay up for longer than it used to.
On 3/8/07, Marnie McCormack <ma...@googlemail.com> wrote:
> In previous projects we had a lot of problems with cruisecontrol falling
> over, very frequently. It may be that the current release is more stable
> than previously though.
>
> Bfn,
> Marnie
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Marnie McCormack <ma...@googlemail.com>.
In previous projects we had a lot of problems with cruisecontrol falling
over, very frequently. It may be that the current release is more stable
than previously though.
Bfn,
Marnie
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Rupert Smith <ru...@googlemail.com>.
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 <ac...@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.
>
>
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back
in order
Posted by Alan Conway <ac...@redhat.com>.
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.
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back
in order
Posted by Nuno Santos <ns...@redhat.com>.
Rupert Smith wrote:
> The only condition they asked for is that we put an acknowledgement on
> the project web site.
> If RedHat are going to supply a box or two (need Windows and Linux),
> available on the internet, that would be ideal. I was thinking of
> getting it running here and figuring out if I can publish a results
> page to the Wiki, that would be a start anyway. Can add email spamming
> later.
Our original plan was for an internal build/test machine, which could
email status of an svn-based build to any interested qpid developers.
I'm not certain about our lab policies but I don't think we would be
able to make it an external facing machine available for general project
use, this is something that I'll need to follow up with Carl and our lab
manager.
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.
Nuno
> On 3/6/07, Robert Godfrey <ro...@gmail.com> wrote:
>> +1 on the free license - but what are the conditions on its use?
>> Obviously
>> any continuous build system will have to be hosted on some equipment.
>> How
>> many installations is the license offer good for? If an instance is
>> to be
>> hosted inside the company which employs one of the contributors what
>> are the
>> implications...
>>
>> I have discussed offline with a couple of the guys from RedHat that they
>> will be having their own continuous build machine, which they could
>> configure to mail the group with build/test failures. We only want one
>> continuous build machine doing this or we'll be spamming ourselves
>> unnecessarily. On the other hand the RedHat guys may not want to go
>> the the
>> expense of hosting tests on other platforms / operating systems :-)
>> things
>> that might be more important to those of us who work in a heterogeneous
>> environment.
>>
>> Cheers,
>> Rob
>>
>> On 06/03/07, Rupert Smith <ru...@googlemail.com> wrote:
>> >
>> > I have tried out a few different build servers. I started by looking
>> > at this feature matrix (probably not entirely complete or up to date):
>> >
>> >
>> >
>> http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix
>>
>> >
>> > As you can see there are two that have more green ticks than the
>> > others. Anthill Pro and Viewtier Parabuild. I tried both. Anthill Pro
>> > looks very good (maven build running on my machine, configured in 18
>> > minutes!). Parabuild looked pretty awfull.
>> >
>> > Anthill Pro have offered to give us a free licence as they do this for
>> > open source projects. The Apache Geronimo project has already set the
>> > precedent by also using Anthill Pro 3. They've had their own debate,
>> > around the subject of wether or not they should be using non-free,
>> > non-open source software and whether or not using it will force people
>> > building from a checkout to also use it. Read the debate here:
>> >
>> >
>> >
>> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200612.mbox/ajax/%3c18073DCE-7011-41D0-877F-45DD8F8CA1B8@planet57.com%3e
>>
>> >
>> > To summarize:
>> >
>> > It won't force people to be dependant on anthill, because the build
>> > server and build system are seperate things. The build system is
>> > maven, make, msbuild etc. All anthill does is call it periodically to
>> > do the build. The build system will still need to be maintained and
>> > kept in working order for every day devlopment activity from the
>> > command line.
>> >
>> > As for non-free, non-os software. We already use Jira, Confluence, not
>> > to mention MsBuild and Visual Studio, which kind of takes the moral
>> > argument out of that point of view.
>> >
>> > I'd like to propose that we accept Urban Code's kind offer of a free
>> > licence. Their product is the only one which can do a fully automated
>> > build over multiple languages and operating systems, call our test
>> > scripts and collate the results.
>> >
>> > Rupert
>> >
>>
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Rupert Smith <ru...@googlemail.com>.
The only condition they asked for is that we put an acknowledgement on
the project web site.
As for the number of machines, whether the licence must be attached to
a particular IP address or something, I'm not yet sure. I'll chase up
the request and find out.
If RedHat are going to supply a box or two (need Windows and Linux),
available on the internet, that would be ideal. I was thinking of
getting it running here and figuring out if I can publish a results
page to the Wiki, that would be a start anyway. Can add email spamming
later.
Rupert
On 3/6/07, Robert Godfrey <ro...@gmail.com> wrote:
> +1 on the free license - but what are the conditions on its use? Obviously
> any continuous build system will have to be hosted on some equipment. How
> many installations is the license offer good for? If an instance is to be
> hosted inside the company which employs one of the contributors what are the
> implications...
>
> I have discussed offline with a couple of the guys from RedHat that they
> will be having their own continuous build machine, which they could
> configure to mail the group with build/test failures. We only want one
> continuous build machine doing this or we'll be spamming ourselves
> unnecessarily. On the other hand the RedHat guys may not want to go the the
> expense of hosting tests on other platforms / operating systems :-) things
> that might be more important to those of us who work in a heterogeneous
> environment.
>
> Cheers,
> Rob
>
> On 06/03/07, Rupert Smith <ru...@googlemail.com> wrote:
> >
> > I have tried out a few different build servers. I started by looking
> > at this feature matrix (probably not entirely complete or up to date):
> >
> >
> > http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix
> >
> > As you can see there are two that have more green ticks than the
> > others. Anthill Pro and Viewtier Parabuild. I tried both. Anthill Pro
> > looks very good (maven build running on my machine, configured in 18
> > minutes!). Parabuild looked pretty awfull.
> >
> > Anthill Pro have offered to give us a free licence as they do this for
> > open source projects. The Apache Geronimo project has already set the
> > precedent by also using Anthill Pro 3. They've had their own debate,
> > around the subject of wether or not they should be using non-free,
> > non-open source software and whether or not using it will force people
> > building from a checkout to also use it. Read the debate here:
> >
> >
> > http://mail-archives.apache.org/mod_mbox/geronimo-dev/200612.mbox/ajax/%3c18073DCE-7011-41D0-877F-45DD8F8CA1B8@planet57.com%3e
> >
> > To summarize:
> >
> > It won't force people to be dependant on anthill, because the build
> > server and build system are seperate things. The build system is
> > maven, make, msbuild etc. All anthill does is call it periodically to
> > do the build. The build system will still need to be maintained and
> > kept in working order for every day devlopment activity from the
> > command line.
> >
> > As for non-free, non-os software. We already use Jira, Confluence, not
> > to mention MsBuild and Visual Studio, which kind of takes the moral
> > argument out of that point of view.
> >
> > I'd like to propose that we accept Urban Code's kind offer of a free
> > licence. Their product is the only one which can do a fully automated
> > build over multiple languages and operating systems, call our test
> > scripts and collate the results.
> >
> > Rupert
> >
>
Re: Continuous Build Server. Was: NEED HELP: getting the trunk back in order
Posted by Robert Godfrey <ro...@gmail.com>.
+1 on the free license - but what are the conditions on its use? Obviously
any continuous build system will have to be hosted on some equipment. How
many installations is the license offer good for? If an instance is to be
hosted inside the company which employs one of the contributors what are the
implications...
I have discussed offline with a couple of the guys from RedHat that they
will be having their own continuous build machine, which they could
configure to mail the group with build/test failures. We only want one
continuous build machine doing this or we'll be spamming ourselves
unnecessarily. On the other hand the RedHat guys may not want to go the the
expense of hosting tests on other platforms / operating systems :-) things
that might be more important to those of us who work in a heterogeneous
environment.
Cheers,
Rob
On 06/03/07, Rupert Smith <ru...@googlemail.com> wrote:
>
> I have tried out a few different build servers. I started by looking
> at this feature matrix (probably not entirely complete or up to date):
>
>
> http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix
>
> As you can see there are two that have more green ticks than the
> others. Anthill Pro and Viewtier Parabuild. I tried both. Anthill Pro
> looks very good (maven build running on my machine, configured in 18
> minutes!). Parabuild looked pretty awfull.
>
> Anthill Pro have offered to give us a free licence as they do this for
> open source projects. The Apache Geronimo project has already set the
> precedent by also using Anthill Pro 3. They've had their own debate,
> around the subject of wether or not they should be using non-free,
> non-open source software and whether or not using it will force people
> building from a checkout to also use it. Read the debate here:
>
>
> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200612.mbox/ajax/%3c18073DCE-7011-41D0-877F-45DD8F8CA1B8@planet57.com%3e
>
> To summarize:
>
> It won't force people to be dependant on anthill, because the build
> server and build system are seperate things. The build system is
> maven, make, msbuild etc. All anthill does is call it periodically to
> do the build. The build system will still need to be maintained and
> kept in working order for every day devlopment activity from the
> command line.
>
> As for non-free, non-os software. We already use Jira, Confluence, not
> to mention MsBuild and Visual Studio, which kind of takes the moral
> argument out of that point of view.
>
> I'd like to propose that we accept Urban Code's kind offer of a free
> licence. Their product is the only one which can do a fully automated
> build over multiple languages and operating systems, call our test
> scripts and collate the results.
>
> Rupert
>