incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Date Sun, 12 Aug 2012 14:59:02 GMT


> -----Original Message-----
> From: Darren Shepherd [mailto:darren@godaddy.com]
> Sent: Saturday, August 11, 2012 8:32 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
> 
> All,
> 
> I'd like to give my two cents about the CloudStack build system and this
> 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 good
> 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 feature
> of the current system in that the current system works.
>  So while I agree long term we should probably get to gradle, I think we
> 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 written
> using Spring and Maven and thus I had to figure out how to get those two
> 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 to
> integrate all of our changes. So I also understand building the systemvm.iso
> (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 just
> 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 conventions.
> 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 doing
> yourself and future developers a disservice if your using maven and not
> 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). 

--Alex

Mime
View raw message