> -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Wednesday, August 08, 2012 4:19 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Build systems [was RE: [DISCUSS] Binaries (jars) in our > source tree/source releases.] > > > > > -----Original Message----- > > From: Ewan Mellor [mailto:ewan.mel...@eu.citrix.com] > > Sent: Wednesday, August 08, 2012 3:31 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: Build systems [was RE: [DISCUSS] Binaries (jars) in our > source > > tree/source releases.] > > > > We need to push this discussion on build systems to a conclusion. > Let me > > summarize so far. > > > > * We need to be able to build CloudStack in various configurations > (support > > for the range of hypervisors turned on or off, etc). > > > > * We would like the build tool to be able to get the necessary > dependencies > > automatically, to avoid the user having to download a dozen libraries > from all > > sorts of different places. > > > > * Many of our dependencies are version-dependent, so we would want to > > get a specific version or at the very least have greater-than > constraints on the > > version that is downloaded. > > > > * We want to be able to package CloudStack in RPMs and .debs that > correctly > > depend on packages available on the target platform. > > > > > > Gradle has been proposed: http://www.gradle.org/. No-one seems to > know > > much about it, other than the fact that Hibernate and Spring have > switched > > to using it, so it can't be too bad. > > > > Maven has been proposed: http://maven.apache.org. We have some > > expertise offered from Brett Porter (a committer there). It's an > Apache > > project, and it's very widely used. We don't know much about it > though, > > outside of Brett. I think that there's a legitimate criticism that > it makes it > > difficult for packagers, because it hides the system dependencies. > That > > might not be reason enough not to use it though. I don't know if > Gradle > > suffers from the same problem. > > > > Scripting it all ourselves with Ant is a possibility. David started > this effort on > > the deps-ctrl branch. This puts us in control of our own destiny, > and means > > that we don't have to learn a new tool (or fit in with the way that > the tool > > works). It does sound like we're just going to end up re-inventing > half of > > Maven that way though. > > > > > > For me, it comes down to developer resources. We need people who > care > > about this topic to volunteer some time to get the build working > smoothly. If > > those people want to use Maven or Gradle, I don't think anyone else > is going > > to object too strongly, because no-one seems to know very much about > > those tools. At the least, we get the opportunity to try one of > them, and see > > if we like it. Nothing is ever set in stone, and if we decide to > rewrite the build > > system in time for the 4.1 release, then we can do that. > > > > So that's the big question: is someone going to volunteer to get the > build > > system tamed for the 4.0 release? It's a dirty job, but someone's > got to do it, > > and you'll earn significant kudos if you do! > > > Ivy has also been proposed. It's also part of Apache and works within > Ant and it uses the maven repository. It is important that the build > system doesn't tax the developer, such as making them setup in a > certain way.
Yes, sorry, Ivy too. Any volunteers to work on any of these tools? Ewan.
