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: [MERGE] Merge Javelin branch into master
Date Sat, 05 Jan 2013 00:34:46 GMT


On 1/4/13 4:09 PM, "David Nalley" <david@gnsa.us> wrote:

>On Fri, Jan 4, 2013 at 6: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
>>
>
>Kelven:
>
>As Chip noted earlier today[1], Javelin doesn't currently build when
>tests are enabled, which is troubling.
>
>
>[1] http://markmail.org/message/5qtvdqom4hblw2zg


Yes, this is due to that we were working under "at least make it compile"
mode in javelin as most of us are doing new code development, but this is
changing rapidly, we switched to the mode of "can we run javelin server".

To enable testing in build will need to convert units test to be based on
Spring Junit integration as well. It is pretty straight forward and
hopefully we will be able to get help in this area from community members.
When we are able to launch a functional server in Javelin branch, we will
update the status and invite helps from community on this.

>


Mime
View raw message