incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dsheph...@godaddy.com
Subject Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Date Tue, 14 Aug 2012 23:08:36 GMT
On 2012-08-14 14:31, Hugo Trippaers wrote:
> Heya,
>
> In end both ant and waf will have to go. As per recent discussions we
> should leave the rpm/deb building to the distro's and focus in
> building the jars. In my view also any will be used less, maybe even
> the other way around. Use ant called from maven/gradle to do the few
> things they can't do well (like building devcloud).
>
> For me a focus on building jars and running the test suite is enough
> for now. More features to be added later :-)
>
> Can you send the pom files you have already? I'll add them to the
> gradle branch so we can play around a bit.
>
> Cheers,
>
> Hugo
>
> Sent from my iPhone
>
> On 14 aug. 2012, at 18:07, "dshepherd@godaddy.com"
> <dshepherd@godaddy.com> wrote:
>
>> On 2012-08-14 07:23, Chip Childers wrote:
>>> On Tue, Aug 14, 2012 at 2:55 AM, Hugo Trippaers
>>> <HTrippaers@schubergphilis.com> wrote:
>>>> 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?
>>>
>>> +1
>>>
>>> Darren, how much time do you think you would need to get something
>>> ready for review?
>>>
>>>> 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
>>
>> I'll have something by the end of the week.  The scope of what I'm 
>> trying to accomplish is larger than what has already been done with 
>> gradle.  From what I can see the gradle that has been checked in just 
>> builds the jars (which I already have the same in maven).  I'm also 
>> looking to update ant and waf to call maven so that the rpm/deb build 
>> process will not require the files in the deps.
>>
>> So if somebody was to run "ant build-all" or "./waf build" it will 
>> end up using maven to produce the jars and whatever artifacts.  The 
>> ant/waf part is the hard part.
>>
>> Additionally I'm looking at how we can do a fully OSS build and 
>> non-OSS build.  So its no good if we just don't build the jars, 
>> because also the component.xml refers to them.
>>
>> And finally I'm trying to determine how this will fit into the 
>> technical release process.  Maven or gradle adds additional steps to 
>> the process of updating version number and publishing to repos, so 
>> that needs to be integrated.
>>
>> So in the end I have a much larger end-to-end picture I'm working 
>> on.  Let me know if you don't want me working on these things.
>>
>> Darren

I think I may have assumed too much.  So what you've done with gradle, 
is that from your perspective a complete solution for this stage in the 
game?  If that's all you were trying to accomplish, building the jars, 
then ship it.

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.

Hugo, if you feel good with what you've done you should continue 
forward with gradle and I'll just drop whatever I'm doing.  I feel like 
I'm going against the grain for no good reason.  At the end of the day 
some committer is going to need to maintain the build system so I'd feel 
better with letting the existing CS team handle this.  So I'm going to 
just stop with maven at this point.

Darren

Mime
View raw message