cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: what is the plan for the build system?
Date Tue, 16 Oct 2012 11:04:04 GMT

On 16-Oct-2012, at 2:15 PM, Noa Resare <> wrote:

> Hello friends,
> I've been tasked with looking into the possibility of running cloudstack on
> Debian stable, and based on my preliminary investigations I have a few
> questions that I hope that someone can answer.
> * What is the long term plan for the build system? Right now we use Make
> (debian/rules), waf, maven and ant and that setup doesn't exactly lend
> itself to a gentle learning curve. Also, it builds everything (at least)
> twice.

On master, we've already started using maven for building and development:

Hugo/Edison/Wido can update on packaging etc. Current work on rpm packaging is done in the
maven-rpm branch;;a=shortlog;h=refs/heads/maven-to-rpm

> * Using maven for populating the deps directory, with repositories and
> transitive dependencies has a bad habit of breaking in surprising ways.
> Since third party pom files can inject repository references to
> repositories that returns bad data it's a fragile process. I'd like to
> spend some time improving this, and there are a few ways of doing it, none
> of which is obviously the right way to go. Where would I ideally direct my
> efforts?

deps/ will soon go away, or get fixed. This was needed only for ant, but it's open for discussion.

> * There are some dependencies to specific versions of some java
> dependencies not available in Debian squeeze (commons-codec, log4j). What
> is the rationale for adding those as dependencies instead of pulling the
> exact version that we want via maven, since we are downloading >100M of
> dependencies anyway?

We've had such experience before. But the issue is more complicated:
If we include all the dependencies required by CloudStack in cloud-deps (which is the cloudstack
dependency package), the installation breaks if say there is a package (say commons-codec)
which was already installed on that particular setup. This fails for distros like Debian Squeeze
too where there is no package by that name in its default repository.

One solution could be that we bundle all the dependency in cloud-deps, and use filename prefix
cloud-, but again this could lead to class loading conflicts due to the way the class loader

For 4.0, the debian/control was configured as per Ubuntu 12.04 LTS. You can download the builds
from or use this repository:

You can add/remove deps from bld.install_files() in wscript_build and configure debian/* as
needed and build your own package for Debian.


> -- 
> Developer, Engineering Experience, Spotify

View raw message