Looking at Darren's emails, and your earlier +1.01 for Maven, I was going to say that we should go with Maven just because of the additional experience that we have between us. I know that Darren has done a lot with Maven in the past, and he is willing to help.
If you want to continue with both Maven and Gradle for now, in the interests of science, then that's OK by me too. It's really up to you if you want to put the time into trying both. We need to make a decision soon though. Is it OK if I set a deadline of EOD tomorrow for your branches to be ready, and then we can have a vote in the IRC meeting on Friday, 17:00 UTC? Ewan. > -----Original Message----- > From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com] > Sent: 14 August 2012 22:29 > To: <cloudstack-dev@incubator.apache.org> > Cc: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS] Binaries (jars) in our source tree/source releases. > > Only releasing jar files is certainly not the idea. Next to that there is > other > stuff that we need to do like building system vms and stuff. > > My idea was more to see if maven/gradle can be the leading build tool, > driving other tools to do the other jobs. > > I would still like to see what you have done with maven so far. I'm also more > familiar with maven, but gradle looks promising. Hence the double work. I > would like to show both to the dev community so we can make an informed > choice. > > Cheers, > > Hugo > > > > Sent from my iPhone > > On 15 aug. 2012, at 02:23, "Alex Huang" <alex.hu...@citrix.com> wrote: > > >> > >> I have no clue what the technical release process is, like how you > >> are really going to build Apache CS and produce a release > >> distribution. I have a good idea of how Citrix used to do it, but > >> for Apache CS if all we want to do is release jars, we can stop at gradle. > >> > > I don't think Apache CS will only release jar files. > > > > I once planned for CloudStack to be a bunch of components driven by a > orchestration engine. Components.xml was written originally intending for > administrators to specify at deployment time the components that can be > deployed and used by the orchestration engine. CS is no longer like that and > it will take a while to get it back to that type of state. The appeal of CS > today > is that it is a product and we should release it as such for now. > > > > --Alex
