Alex, 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.
Darren -------- Original Message -------- Subject: RE: [DISCUSS] Binaries (jars) in our source tree/source releases. From: Alex Huang <[email protected]> Date: Sun, August 12, 2012 7:59 am To: "[email protected]" <[email protected]> > -----Original Message----- > From: Darren Shepherd [mailto:[email protected]] > Sent: Saturday, August 11, 2012 8:32 PM > To: [email protected] > 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
