incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Shepherd" <>
Subject RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Date Sun, 12 Aug 2012 15:19:13 GMT

By packaging what do you mean?  I don't think maven should be used to
produce rpms and debs, if thats what you mean.  What I'm proposing at
the moment is really just use maven to build the jars.  So the existing
rpm spec/debian rules and waf will largely remain as is.  I would also
plan to keep some parts of the ant as things like the recent DevCloud
are implemented in ant.  For ant I really have to dig in more and see
what parts would make sense to keep around.  I'm really at the moment
just looking for the simplest way to plug into the maven ecosystem as I
believe that is a crucial first step before bringing in more frameworks
like Spring and JPA.


  -------- Original Message --------
 Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source
 From: Alex Huang <>
 Date: Sun, August 12, 2012 7:59 am
 To: ""
 > -----Original Message-----
 > From: Darren Shepherd []
 > Sent: Saturday, August 11, 2012 8:32 PM
 > To:
 > Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source
 > All,
 > I'd like to give my two cents about the CloudStack build system and
 > current discussion. I tried to read through the whole thread and get
the full
 > context but I apologize if I've missed anything.
 > The problems I've seen with the current build system is that it
 > 1) Packages the binaries dependencies
 > 2) Does not integrate into the maven ecosystem
 > The great thing about the current build system is that it works.
 > Seriously, thats a really compelling feature.
 > So the current build system is spread across
 > * rpm spec
 > * debian rules
 > * waf
 > * ant
 > So in the context of looking for a new build system, it would
probably be best
 > to focus on combining the functionality of waf and ant into one
"thing". The
 > rpm and dpkg should be seperate because the distro specific package
 > managers will always want to have their way and not want to screw
with our
 > gradle or whatever. So I do agree that gradle would probably be a
 > replacement for waf and ant, BUT.... I really don't think thats the
right way to
 > go right now.
 > If one was to try to replace all the functionality of waf and ant,
your signing
 > up for a lot of work right now and it kinda goes against the greatest
 > of the current system in that the current system works.
 > So while I agree long term we should probably get to gradle, I think
 > should focus more on the issues at hand. Here's what I propose. I
think we
 > should look at replacing the majority of the ant scripts with maven
but try to
 > keep the rest of things intact. This will allow us to solve the main
issues with
 > the smallest amount of change in the shortest amount of time. Once we
 > have a maven environment, transitioning to gradle is relatively easy
(if we
 > end up doing that eventually).
 > I'm willing to take on this effort. I have worked a lot of with
CloudStack 2.2 in
 > the past and one of the first things I did with CloudStack was to
figure out
 > how to build it with maven. All of our extensions to CloudStack were
 > using Spring and Maven and thus I had to figure out how to get those
 > frameworks integrated into CloudStack. A lot has change since 2.2,
but I'm
 > sure I could easily figure that out. I'm also very experienced with
the rest of
 > the build process as we had to rebuild CloudStack RPM's from scratch
 > integrate all of our changes. So I also understand building the
 > (if that still exists?), the init scripts, wscript_configure, etc.
I've messed with it
 > all.
 > Let me know if you want me to head down this path. It would probably
 > take me a week or two to knock this out and then you guys can decide
if this
 > is a 4.0 or post-4.0 thing. One huge warning up front though. Maven
is a build
 > by convention framework and kinda likes it if you actually use its
 > This means the directory structure of all the of the java stuff will
be moved
 > around. One could make maven respect the existing layout, but your
 > yourself and future developers a disservice if your using maven and
 > following the conventions.
 +1 I've seen Darren's work in putting CloudStack in maven and Spring
before so I can vouch for his expertise in these areas.
 My only comment is that even if we use the same tool (maven) for build
and packaging, we should do them in distinct steps so other people can
add other types of packaging. Preferably, we specify the transition
stage from build artifact to package (such as where they should be for
each project and/or naming conventions). 

View raw message