Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of darren@godaddy.com designates
 208.109.78.207 as permitted sender)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
User-Agent: Workspace Webmail 5.6.24
Message-Id: 
 <20120812081913.d3d18d9a633cb81ed61112bf108fc615.b0244b3ba6.wbe@email00.secureserver.net>
From: "Darren Shepherd" <darren@godaddy.com>
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Date: Sun, 12 Aug 2012 08:19:13 -0700
Mime-Version: 1.0

Alex,=0A=0ABy packaging what do you mean?  I don't think maven should be us=
ed to=0Aproduce rpms and debs, if thats what you mean.  What I'm proposing =
at=0Athe moment is really just use maven to build the jars.  So the existin=
g=0Arpm spec/debian rules and waf will largely remain as is.  I would also=
=0Aplan to keep some parts of the ant as things like the recent DevCloud=0A=
are implemented in ant.  For ant I really have to dig in more and see=0Awha=
t parts would make sense to keep around.  I'm really at the moment=0Ajust l=
ooking for the simplest way to plug into the maven ecosystem as I=0Abelieve=
 that is a crucial first step before bringing in more frameworks=0Alike Spr=
ing and JPA.=0A=0ADarren=0A=0A=0A  -------- Original Message --------=0A Su=
bject: RE: [DISCUSS] Binaries (jars) in our source tree/source=0A releases.=
=0A From: Alex Huang <Alex.Huang@citrix.com>=0A Date: Sun, August 12, 2012 =
7:59 am=0A To: "cloudstack-dev@incubator.apache.org"=0A <cloudstack-dev@inc=
ubator.apache.org>=0A =0A =0A =0A > -----Original Message-----=0A > From: D=
arren Shepherd [mailto:darren@godaddy.com]=0A > Sent: Saturday, August 11, =
2012 8:32 PM=0A > To: cloudstack-dev@incubator.apache.org=0A > Subject: RE:=
 [DISCUSS] Binaries (jars) in our source tree/source=0Areleases.=0A > =0A >=
 All,=0A > =0A > I'd like to give my two cents about the CloudStack build s=
ystem and=0Athis=0A > current discussion. I tried to read through the whole=
 thread and get=0Athe full=0A > context but I apologize if I've missed anyt=
hing.=0A > =0A > The problems I've seen with the current build system is th=
at it=0A > =0A > 1) Packages the binaries dependencies=0A > 2) Does not int=
egrate into the maven ecosystem=0A > =0A > The great thing about the curren=
t build system is that it works.=0A > Seriously, thats a really compelling =
feature.=0A > =0A > So the current build system is spread across=0A > =0A >=
 * rpm spec=0A > * debian rules=0A > * waf=0A > * ant=0A > =0A > So in the =
context of looking for a new build system, it would=0Aprobably be best=0A >=
 to focus on combining the functionality of waf and ant into one=0A"thing".=
 The=0A > rpm and dpkg should be seperate because the distro specific packa=
ge=0A > managers will always want to have their way and not want to screw=
=0Awith our=0A > gradle or whatever. So I do agree that gradle would probab=
ly be a=0Agood=0A > replacement for waf and ant, BUT.... I really don't thi=
nk thats the=0Aright way to=0A > go right now.=0A > =0A > If one was to try=
 to replace all the functionality of waf and ant,=0Ayour signing=0A > up fo=
r a lot of work right now and it kinda goes against the greatest=0Afeature=
=0A > of the current system in that the current system works.=0A > So while=
 I agree long term we should probably get to gradle, I think=0Awe=0A > shou=
ld focus more on the issues at hand. Here's what I propose. I=0Athink we=0A=
 > should look at replacing the majority of the ant scripts with maven=0Abu=
t try to=0A > keep the rest of things intact. This will allow us to solve t=
he main=0Aissues with=0A > the smallest amount of change in the shortest am=
ount of time. Once we=0A > have a maven environment, transitioning to gradl=
e is relatively easy=0A(if we=0A > end up doing that eventually).=0A > =0A =
> I'm willing to take on this effort. I have worked a lot of with=0ACloudSt=
ack 2.2 in=0A > the past and one of the first things I did with CloudStack =
was to=0Afigure out=0A > how to build it with maven. All of our extensions =
to CloudStack were=0Awritten=0A > using Spring and Maven and thus I had to =
figure out how to get those=0Atwo=0A > frameworks integrated into CloudStac=
k. A lot has change since 2.2,=0Abut I'm=0A > sure I could easily figure th=
at out. I'm also very experienced with=0Athe rest of=0A > the build process=
 as we had to rebuild CloudStack RPM's from scratch=0Ato=0A > integrate all=
 of our changes. So I also understand building the=0Asystemvm.iso=0A > (if =
that still exists?), the init scripts, wscript_configure, etc.=0AI've messe=
d with it=0A > all.=0A > =0A > Let me know if you want me to head down this=
 path. It would probably=0Ajust=0A > take me a week or two to knock this ou=
t and then you guys can decide=0Aif this=0A > is a 4.0 or post-4.0 thing. O=
ne huge warning up front though. Maven=0Ais a build=0A > by convention fram=
ework and kinda likes it if you actually use its=0Aconventions.=0A > This m=
eans the directory structure of all the of the java stuff will=0Abe moved=
=0A > around. One could make maven respect the existing layout, but your=0A=
doing=0A > yourself and future developers a disservice if your using maven =
and=0Anot=0A > following the conventions.=0A > =0A =0A +1 I've seen Darren'=
s work in putting CloudStack in maven and Spring=0Abefore so I can vouch fo=
r his expertise in these areas.=0A =0A My only comment is that even if we u=
se the same tool (maven) for build=0Aand packaging, we should do them in di=
stinct steps so other people can=0Aadd other types of packaging. Preferably=
, we specify the transition=0Astage from build artifact to package (such as=
 where they should be for=0Aeach project and/or naming conventions). =0A =
=0A --Alex