incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: Build systems [was RE: [DISCUSS] Binaries (jars) in our source tree/source releases.]
Date Wed, 08 Aug 2012 23:18:36 GMT

> -----Original Message-----
> From: Ewan Mellor []
> Sent: Wednesday, August 08, 2012 3:31 PM
> To:
> 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:  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:  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.


View raw message