On 1/4/13 3:53 PM, "Marcus Sorensen" <shadow...@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.y...@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 >> >>
