cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <>
Subject RE: [DISCUSS] Binaries (jars) in our source tree/source releases.
Date Tue, 14 Aug 2012 06:55:55 GMT
Hey all,

Good to see action on this, we've been discussing this for a long time and I think we need
to get moving. At least on the "building jars" front we seem to be narrowing down to two contenders
maven and grade. Darren is doing the maven thing and I've pushed to gradle build script to
the gradle branch in the ASF repo. (@Darren, feel free to have a look at it, all the dependencies
are in there including version numbers in maven format, might save you some work)

I propose we put it into a vote when Darren is ready and we can do a side-by-side comparison
of gradle versus maven?

Next up would be the rpms/deb/snowballs  packaging method, but that is for later and I think
both maven and grade are not ideal choices for this. I'd rather see something as simple as
fpm in there. But that a discussion for another day ;-)



-----Original Message-----
From: Darren Shepherd [] 
Sent: Tuesday, August 14, 2012 4:14 AM
Subject: Re: [DISCUSS] Binaries (jars) in our source tree/source releases.

As I said before we don't *have* to move the files around.  I already started working on this
(I have everything compiling fine) and have taken the approach of not moving files.  Moving
the files around is just nice because it's easier for other people who don't know CS but know
maven to work with CS.  I think I'll implement this with no moving and then maybe after 4.0
we talk about restructuring as I agree it will be very disruptive.

Gradle is possibly a good replacement for waf and ant if your looking for a general purpose
build system.  But right now we really just need to worry about the points I mentioned before.
 So in the approach I'm thinking waf and ant still remain in some form to retain compatibility
with what everyone working on CS is used to.  So we can accomplish what we need with the smallest

So it would be difficult to replace everything right now with Gradle. 
Meaning not only do you rewrite the entire build system you also have to update documentation
(wiki stuff), other scripts (jenkins, devcloud, test harnesses, etc), and everybody needs
to learn a new system.  We could do waf, ant, and gradle instead of waf, ant, and maven but
I would only do that if we were 100% sure gradle is the best way to go.  So in my comments
I've always said gradle is *probably* a good solution, but honestly if the decision was up
to me I'd say no, just stick with maven.
 At the end of the day you just need something that builds the system and you don't need to
worry much about it.  We don't exactly need to be pioneers in this area.  Maven works, has
a gigantic community, tons of plugins (like all this license updating work could have been
done with 1 of many license management maven plugins), tons of info on google and excellent
Eclipse integration that really does work (m2e is an eclipse foundation project).  Basically
you can't really go to wrong with Maven.
 With gradle you narrow everything, smaller community, less tools, etc. 
So I'd leave gradle to camps like Spring that enjoy reinventing everything themselves anyways.



Sent from my iPhone

On Aug 13, 2012, at 5:37 PM, Ewan Mellor <>

>> -----Original Message-----
>> From: Darren Shepherd []
>> [Snip]
>> 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.
> It's this "use our conventions" bit that worries people, I think.  The CloudStack conventions
certainly aren't Maven-friendly, and it would be a lot of churn on the codebase and arguably
a backwards step if we were to adopt all their conventions.  Do you know if Gradle suffers
from the same problem?  In other words, if we switched to Gradle would we still have to move
all the code around?
> Also, could you explain why you think that a switch to Maven would be easy but a switch
to Gradle would be hard?
> In general, I'm happy to take build system changes pretty much right up to the last minute.
  Any regressions are likely to be immediate and obvious, unless the more subtle regressions
you get when working with the code itself.  I'm also keen to make sure that build from source
is easy for people, since this will be the primary release mechanism now.  However, if we're
going to have to move all the files around, we'll never be able to manage the release branch
properly, so that would rule this out for 4.0 if that's going to be necessary.
> Cheers,
> Ewan.
View raw message