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 ;-) Cheers, Hugo -----Original Message----- From: Darren Shepherd [mailto:dar...@godaddy.com] Sent: Tuesday, August 14, 2012 4:14 AM To: cloudstack-dev@incubator.apache.org Cc: cloudstack-dev@incubator.apache.org 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 disruption. 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. Darren Sent from my iPhone On Aug 13, 2012, at 5:37 PM, Ewan Mellor <ewan.mel...@eu.citrix.com> wrote: >> -----Original Message----- >> From: Darren Shepherd [mailto:dar...@godaddy.com] >> >> [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. >
