incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <kelven.y...@citrix.com>
Subject Re: [PROPOSAL] Merge Javelin branch into master
Date Sat, 05 Jan 2013 00:18:57 GMT


On 1/4/13 3:53 PM, "Marcus Sorensen" <shadowsor@gmail.com> wrote:

>I'm worried that a few things we're working on against master will break
>and I'll have to figure out the code that's in javelin in order to merge
>my
>stuff (as opposed to having more help of other people trying to merge
>javelin in after my changes), which may delay things considerably, but
>javelin needs to be merged at some point, and its probably unreasonable to
>delay unless there are a lot of others in the same boat. Maybe we can set
>a
>date for next Friday or something?


Javelin merge will be after api-refactoring merge if it is approved by the
community. Some time at next week's time frame looks like a good time



>On Jan 4, 2013 4:13 PM, "Kelven Yang" <kelven.yang@citrix.com> wrote:
>
>> I'm proposing another branch merge after API-refactoring branch, to
>>merge
>> javelin branch into the main stream. Javelin branch contains a number of
>> architecture refactoring efforts,
>>
>> 1. Adopting Spring Framework for dependency injection of CloudStack
>> internal components
>> 2. IPC framework for inter component communications
>> 3. Storage subsystem refactoring
>> 4. CloudStack Orchestration Engine refactoring
>>
>> Majorities of the new refactoring work are independent of existing
>> CloudStack components, therefore merging these independent newly
>>developed
>> components should not have a big impact to existing code base. The major
>> impact of this merge will be on #1, as it touches almost every component
>> in the existing code base, DAOs, Adapters, Managers, etc. In order to
>> seamlessly replace our existing ComponentLocator with Spring injection
>> framework. We've done following refactoring to existing code base.
>>
>> 1) Remove all un-necessary runtime bindings to ComponentLocator at Daos,
>> Managers, Adapters, etc
>> 2) Using standard javax @Inject to replace with customized
>> com.cloud.utils.component.Inject
>> 3) Using Spring AOP to support @DB semantics
>> 4) Separate component loading and initializing to avoid inter-leaving
>> dependencies between Spring bootstrap loader and CloudStack run-time
>> business logic.
>> 5) Move CloudStack bootstrap logic out of ComponentLocator to the
>> initialization process at business logic layer
>>
>> The plan of performing such merge will be, we will first pull the latest
>> master content into javelin branch, complete the merge at javelin branch
>> and commit it into master after certain level of testing. The goal is to
>> make existing code works as before but will drop in newly add-ons of
>> refactoring work.
>>
>> Kelven
>>
>>


Mime
View raw message