incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [MERGE] Merge Javelin branch into master
Date Mon, 07 Jan 2013 15:26:24 GMT
On Fri, Jan 4, 2013 at 7:34 PM, Kelven Yang <kelven.yang@citrix.com> wrote:
>
>
> 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.

IMO, the resulting merge should include fixes to any broken unit
tests.  It would be nice for there to also be unit tests for the new
classes.  Let everyone know when you are ready for help on the unit
tests fixes, and I'm sure folks will step up to help out (I'll
certainly do a few).

Assuming that the tests are fixed prior to the merge into master, the
plan above looks good to me.

-chip

Mime
View raw message