incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ewan Mellor <Ewan.Mel...@eu.citrix.com>
Subject RE: Build systems [was RE: [DISCUSS] Binaries (jars) in our source tree/source releases.]
Date Wed, 08 Aug 2012 23:21:15 GMT
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@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.Mellor@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.


Mime
View raw message