Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of rohit.yadav@citrix.com
 designates 203.166.19.134 as permitted sender)
From: Rohit Yadav <rohit.yadav@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Tue, 16 Oct 2012 16:34:04 +0530
Subject: Re: what is the plan for the build system?
Thread-Topic: what is the plan for the build system?
Thread-Index: Ac2rjfSaReUTWRxuStCDDMbzULyQ9w==
Message-ID: <EC848E51-2305-42FD-856A-7E97D5F1BBB6@citrix.com>
References: 
 <CANc7MVxN=Qt7_N2trG9rc2AcCFGxewBpaad3Ho6Oh=_PgE+OdA@mail.gmail.com>
In-Reply-To: 
 <CANc7MVxN=Qt7_N2trG9rc2AcCFGxewBpaad3Ho6Oh=_PgE+OdA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 16-Oct-2012, at 2:15 PM, Noa Resare <noa@spotify.com> wrote:

> Hello friends,
>=20
> 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.
>=20
> * 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: =
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+with+Maven#=
BuildingwithMaven-BuildingCloudStack

Hugo/Edison/Wido can update on packaging etc. Current work on rpm packaging=
 is done in the maven-rpm branch; https://git-wip-us.apache.org/repos/asf?p=
=3Dincubator-cloudstack.git;a=3Dshortlog;h=3Drefs/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, non=
e
> of which is obviously the right way to go. Where would I ideally direct m=
y
> 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 (wh=
ich is the cloudstack dependency package), the installation breaks if say t=
here is a package (say commons-codec) which was already installed on that p=
articular 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 conf=
licts due to the way the class loader works.

For 4.0, the debian/control was configured as per Ubuntu 12.04 LTS. You can=
 download the builds from jenkins.cloudstack.org or use this repository: ht=
tp://cloudstack.apt-get.eu

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

Regards.

>=20
>=20
>=20
>=20
> --=20
> Developer, Engineering Experience, Spotify