You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Kelven Yang <ke...@citrix.com> on 2013/01/05 00:13:27 UTC
[PROPOSAL] Merge Javelin branch into master
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
RE: [MERGE] Merge Javelin branch into master
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Hey,
While I'm more than happy to migrate the sources to the maven "standard" layout, we didn't do this yet. The reasoning was that we were running in a hybrid situation with both maven and ant for a while. 4.1 will be the first release with a "full" maven build.
My proposal would be to leave this till 4.1 is out the door. My current focus is getting packaging done and remove waf. Once that is finished we can focus on cleaning up the sources and making everything look more like a maven structure. As far as I know this is purely cosmetic, so we have no pressing reason to do it right now.
Cheers,
Hugo
-----Original Message-----
From: Howie Yu [mailto:howie_yu@trend.com.tw]
Sent: woensdag 9 januari 2013 2:58
To: cloudstack-dev@incubator.apache.org
Subject: Re: [MERGE] Merge Javelin branch into master
Hi Alex
Yes, You are right . I can add testSourceDirectory into pom.xml. I just want to make sure why not use maven conversion layout ~:)
If I write any unit test for any module , should I still follow the standard way post my code into review board?
Beside, I find Javelin branch have some error on pom.xml file , can I report here?
--------------------------
incubator-cloudstack/framework/ipc/pom.xml) has 1 error Not authorized, ReasonPhrase:Unauthorized. and 'parent.relativePath'
points at wrong local POM @ line 15, column 11 ->
I think the pom.xml of cloud-framework-ipc use wrong parent
The parent pom should be cloudstack-framework
<parent>
<groupId>org.apache.cloudstack</groupId>
<artifactId>cloudstack-framework</artifactId>
<version>4.1.0-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath>
</parent>
Not cloud-engine
<parent>
<groupId>org.apache.cloudstack</groupId>
<artifactId>cloud-engine</artifactId>
<version>4.1.0-SNAPSHOT</version>
<relativePath>../../pom.xml</relativePath>
</parent>
On 13/1/9 上午1:08, "Alex Huang" <Al...@citrix.com> wrote:
>> The problem that Howie is talking about is that none of our projects
>> are structured in the "standard" maven layout. This isn't just a
>> test source issue.
>>
>I'm saying maven have a way to accommodate for that by specifying
>exactly where the directory should be in the pom.xml.
>
>Like I said though, I don't know why it doesn't follow standard layout.
>Maybe it was just easier to do the maven conversion this way? I think
>all the directories in javelin has follow the current layout in 4.0 as
>well. We can make all of the javelin directories follow the standard
>if there was no clear call on how to layout the structures originally.
>
>--Alex
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
</pre></td></tr></table>
RE: [MERGE] Merge Javelin branch into master
Posted by Alex Huang <Al...@citrix.com>.
To do it is not that difficult. One person can probably do it in a day. But I think Chip is saying that it was decided to keep the current directory structure because that question was asked b4.
--Alex
> -----Original Message-----
> From: Mohammad Nour El-Din [mailto:nour.mohammad@gmail.com]
> Sent: Tuesday, January 08, 2013 2:16 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [MERGE] Merge Javelin branch into master
>
> Hi...
>
> For the points about following or not following the std Maven directory
> structure, I would suggest to do it after merging Javelin into master branch
>
> Is there a separate branch for updating similar maven configurations ? or
> making our poms comply to the std Maven conventions ?
>
> If not would it be worthy to create that branch gather interested people to
> work on it ?
>
> Thoughts ?
>
>
> On Tue, Jan 8, 2013 at 9:21 PM, John Burwell <jb...@basho.com> wrote:
>
> > Edison,
> >
> > Cool. Sorry for the mini-freak out. I also posted my design thoughts to
> > the "new storage framework update" thread started a little bit back.
> >
> > Thanks,
> > -John
> >
> > On Jan 8, 2013, at 3:07 PM, Edison Su <Ed...@citrix.com> wrote:
> >
> > > Yes, there is no immediate change to s3-backed storage code on master
> > branch after javelin is merged into master. As I haven't glue the new
> > storage code on javelin branch with storage related api calls yet, so all
> > the existing storage code on master will/should work as it is.
> > > After the merge, we can decide when to use the new storage framework
> > code. I think all we agree on that the storage code needs to be refactored,
> > and if then we agree on how to do it, that will be the time we can switch
> > to new storage code.
> > >
> > >> -----Original Message-----
> > >> From: John Burwell [mailto:jburwell@basho.com]
> > >> Sent: Tuesday, January 08, 2013 10:44 AM
> > >> To: cloudstack-dev@incubator.apache.org
> > >> Subject: Re: [MERGE] Merge Javelin branch into master
> > >>
> > >> Edison,
> > >>
> > >> So the current changes for S3-backed Secondary Storage will not be
> > impacted
> > >> by the Javelin's new storage architecture?
> > >>
> > >> Thanks,
> > >> -John
> > >>
> > >> On Jan 8, 2013, at 1:21 PM, Edison Su <Ed...@citrix.com> wrote:
> > >>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: John Burwell [mailto:jburwell@basho.com]
> > >>>> Sent: Tuesday, January 08, 2013 9:13 AM
> > >>>> To: cloudstack-dev@incubator.apache.org
> > >>>> Subject: Re: [MERGE] Merge Javelin branch into master
> > >>>>
> > >>>> All,
> > >>>>
> > >>>> Will this merge be pre or post 4.1.0? I am concerned regarding the
> > >>>> S3-backed
> > >>>
> > >>> Plan before 4.1.0.
> > >>>
> > >>>> Secondary Storage feature. Looking at this branch, the work done to
> > >>>> support
> > >>>> S3 does not appear to compatible with the new storage architecture,
> > >>>> and I don't think there is enough time before 31 Jan 2013 to
> > >>>> retrofit. I also have
> > >>>
> > >>> The existing storage code on master will not be changed, as the most
> > of our
> > >> changes on javelin branch are in the fresh new maven projects.
> > >>>
> > >>>> design concerns which I raise on a separate thread.
> > >>>
> > >>>
> > >>> I'd like to know your comments on the design.
> > >>>
> > >>>>
> > >>>> Thanks,
> > >>>> -John
> > >>>>
> > >>>> On Jan 8, 2013, at 12:08 PM, Alex Huang <Al...@citrix.com>
> > wrote:
> > >>>>
> > >>>>>> The problem that Howie is talking about is that none of our
> > >>>>>> projects are structured in the "standard" maven layout. This isn't
> > >>>>>> just a test source issue.
> > >>>>>>
> > >>>>> I'm saying maven have a way to accommodate for that by specifying
> > >>>>> exactly
> > >>>> where the directory should be in the pom.xml.
> > >>>>>
> > >>>>> Like I said though, I don't know why it doesn't follow standard
> > layout.
> > >>>> Maybe it was just easier to do the maven conversion this way? I
> > >>>> think all the directories in javelin has follow the current layout in
> > >>>> 4.0 as well. We can make all of the javelin directories follow the
> > >>>> standard if there was no clear call on how to layout the structures
> > >> originally.
> > >>>>>
> > >>>>> --Alex
> > >>>
> > >
> >
> >
>
>
> --
> Thanks
> - Mohammad Nour
> ----
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein
Re: [MERGE] Merge Javelin branch into master
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Hi...
For the points about following or not following the std Maven directory
structure, I would suggest to do it after merging Javelin into master branch
Is there a separate branch for updating similar maven configurations ? or
making our poms comply to the std Maven conventions ?
If not would it be worthy to create that branch gather interested people to
work on it ?
Thoughts ?
On Tue, Jan 8, 2013 at 9:21 PM, John Burwell <jb...@basho.com> wrote:
> Edison,
>
> Cool. Sorry for the mini-freak out. I also posted my design thoughts to
> the "new storage framework update" thread started a little bit back.
>
> Thanks,
> -John
>
> On Jan 8, 2013, at 3:07 PM, Edison Su <Ed...@citrix.com> wrote:
>
> > Yes, there is no immediate change to s3-backed storage code on master
> branch after javelin is merged into master. As I haven't glue the new
> storage code on javelin branch with storage related api calls yet, so all
> the existing storage code on master will/should work as it is.
> > After the merge, we can decide when to use the new storage framework
> code. I think all we agree on that the storage code needs to be refactored,
> and if then we agree on how to do it, that will be the time we can switch
> to new storage code.
> >
> >> -----Original Message-----
> >> From: John Burwell [mailto:jburwell@basho.com]
> >> Sent: Tuesday, January 08, 2013 10:44 AM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: Re: [MERGE] Merge Javelin branch into master
> >>
> >> Edison,
> >>
> >> So the current changes for S3-backed Secondary Storage will not be
> impacted
> >> by the Javelin's new storage architecture?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jan 8, 2013, at 1:21 PM, Edison Su <Ed...@citrix.com> wrote:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: John Burwell [mailto:jburwell@basho.com]
> >>>> Sent: Tuesday, January 08, 2013 9:13 AM
> >>>> To: cloudstack-dev@incubator.apache.org
> >>>> Subject: Re: [MERGE] Merge Javelin branch into master
> >>>>
> >>>> All,
> >>>>
> >>>> Will this merge be pre or post 4.1.0? I am concerned regarding the
> >>>> S3-backed
> >>>
> >>> Plan before 4.1.0.
> >>>
> >>>> Secondary Storage feature. Looking at this branch, the work done to
> >>>> support
> >>>> S3 does not appear to compatible with the new storage architecture,
> >>>> and I don't think there is enough time before 31 Jan 2013 to
> >>>> retrofit. I also have
> >>>
> >>> The existing storage code on master will not be changed, as the most
> of our
> >> changes on javelin branch are in the fresh new maven projects.
> >>>
> >>>> design concerns which I raise on a separate thread.
> >>>
> >>>
> >>> I'd like to know your comments on the design.
> >>>
> >>>>
> >>>> Thanks,
> >>>> -John
> >>>>
> >>>> On Jan 8, 2013, at 12:08 PM, Alex Huang <Al...@citrix.com>
> wrote:
> >>>>
> >>>>>> The problem that Howie is talking about is that none of our
> >>>>>> projects are structured in the "standard" maven layout. This isn't
> >>>>>> just a test source issue.
> >>>>>>
> >>>>> I'm saying maven have a way to accommodate for that by specifying
> >>>>> exactly
> >>>> where the directory should be in the pom.xml.
> >>>>>
> >>>>> Like I said though, I don't know why it doesn't follow standard
> layout.
> >>>> Maybe it was just easier to do the maven conversion this way? I
> >>>> think all the directories in javelin has follow the current layout in
> >>>> 4.0 as well. We can make all of the javelin directories follow the
> >>>> standard if there was no clear call on how to layout the structures
> >> originally.
> >>>>>
> >>>>> --Alex
> >>>
> >
>
>
--
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Re: [MERGE] Merge Javelin branch into master
Posted by John Burwell <jb...@basho.com>.
Edison,
Cool. Sorry for the mini-freak out. I also posted my design thoughts to the "new storage framework update" thread started a little bit back.
Thanks,
-John
On Jan 8, 2013, at 3:07 PM, Edison Su <Ed...@citrix.com> wrote:
> Yes, there is no immediate change to s3-backed storage code on master branch after javelin is merged into master. As I haven't glue the new storage code on javelin branch with storage related api calls yet, so all the existing storage code on master will/should work as it is.
> After the merge, we can decide when to use the new storage framework code. I think all we agree on that the storage code needs to be refactored, and if then we agree on how to do it, that will be the time we can switch to new storage code.
>
>> -----Original Message-----
>> From: John Burwell [mailto:jburwell@basho.com]
>> Sent: Tuesday, January 08, 2013 10:44 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [MERGE] Merge Javelin branch into master
>>
>> Edison,
>>
>> So the current changes for S3-backed Secondary Storage will not be impacted
>> by the Javelin's new storage architecture?
>>
>> Thanks,
>> -John
>>
>> On Jan 8, 2013, at 1:21 PM, Edison Su <Ed...@citrix.com> wrote:
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: John Burwell [mailto:jburwell@basho.com]
>>>> Sent: Tuesday, January 08, 2013 9:13 AM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: Re: [MERGE] Merge Javelin branch into master
>>>>
>>>> All,
>>>>
>>>> Will this merge be pre or post 4.1.0? I am concerned regarding the
>>>> S3-backed
>>>
>>> Plan before 4.1.0.
>>>
>>>> Secondary Storage feature. Looking at this branch, the work done to
>>>> support
>>>> S3 does not appear to compatible with the new storage architecture,
>>>> and I don't think there is enough time before 31 Jan 2013 to
>>>> retrofit. I also have
>>>
>>> The existing storage code on master will not be changed, as the most of our
>> changes on javelin branch are in the fresh new maven projects.
>>>
>>>> design concerns which I raise on a separate thread.
>>>
>>>
>>> I'd like to know your comments on the design.
>>>
>>>>
>>>> Thanks,
>>>> -John
>>>>
>>>> On Jan 8, 2013, at 12:08 PM, Alex Huang <Al...@citrix.com> wrote:
>>>>
>>>>>> The problem that Howie is talking about is that none of our
>>>>>> projects are structured in the "standard" maven layout. This isn't
>>>>>> just a test source issue.
>>>>>>
>>>>> I'm saying maven have a way to accommodate for that by specifying
>>>>> exactly
>>>> where the directory should be in the pom.xml.
>>>>>
>>>>> Like I said though, I don't know why it doesn't follow standard layout.
>>>> Maybe it was just easier to do the maven conversion this way? I
>>>> think all the directories in javelin has follow the current layout in
>>>> 4.0 as well. We can make all of the javelin directories follow the
>>>> standard if there was no clear call on how to layout the structures
>> originally.
>>>>>
>>>>> --Alex
>>>
>
RE: [MERGE] Merge Javelin branch into master
Posted by Edison Su <Ed...@citrix.com>.
Yes, there is no immediate change to s3-backed storage code on master branch after javelin is merged into master. As I haven't glue the new storage code on javelin branch with storage related api calls yet, so all the existing storage code on master will/should work as it is.
After the merge, we can decide when to use the new storage framework code. I think all we agree on that the storage code needs to be refactored, and if then we agree on how to do it, that will be the time we can switch to new storage code.
> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com]
> Sent: Tuesday, January 08, 2013 10:44 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [MERGE] Merge Javelin branch into master
>
> Edison,
>
> So the current changes for S3-backed Secondary Storage will not be impacted
> by the Javelin's new storage architecture?
>
> Thanks,
> -John
>
> On Jan 8, 2013, at 1:21 PM, Edison Su <Ed...@citrix.com> wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: John Burwell [mailto:jburwell@basho.com]
> >> Sent: Tuesday, January 08, 2013 9:13 AM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: Re: [MERGE] Merge Javelin branch into master
> >>
> >> All,
> >>
> >> Will this merge be pre or post 4.1.0? I am concerned regarding the
> >> S3-backed
> >
> > Plan before 4.1.0.
> >
> >> Secondary Storage feature. Looking at this branch, the work done to
> >> support
> >> S3 does not appear to compatible with the new storage architecture,
> >> and I don't think there is enough time before 31 Jan 2013 to
> >> retrofit. I also have
> >
> > The existing storage code on master will not be changed, as the most of our
> changes on javelin branch are in the fresh new maven projects.
> >
> >> design concerns which I raise on a separate thread.
> >
> >
> > I'd like to know your comments on the design.
> >
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jan 8, 2013, at 12:08 PM, Alex Huang <Al...@citrix.com> wrote:
> >>
> >>>> The problem that Howie is talking about is that none of our
> >>>> projects are structured in the "standard" maven layout. This isn't
> >>>> just a test source issue.
> >>>>
> >>> I'm saying maven have a way to accommodate for that by specifying
> >>> exactly
> >> where the directory should be in the pom.xml.
> >>>
> >>> Like I said though, I don't know why it doesn't follow standard layout.
> >> Maybe it was just easier to do the maven conversion this way? I
> >> think all the directories in javelin has follow the current layout in
> >> 4.0 as well. We can make all of the javelin directories follow the
> >> standard if there was no clear call on how to layout the structures
> originally.
> >>>
> >>> --Alex
> >
Re: [MERGE] Merge Javelin branch into master
Posted by John Burwell <jb...@basho.com>.
Edison,
So the current changes for S3-backed Secondary Storage will not be impacted by the Javelin's new storage architecture?
Thanks,
-John
On Jan 8, 2013, at 1:21 PM, Edison Su <Ed...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: John Burwell [mailto:jburwell@basho.com]
>> Sent: Tuesday, January 08, 2013 9:13 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [MERGE] Merge Javelin branch into master
>>
>> All,
>>
>> Will this merge be pre or post 4.1.0? I am concerned regarding the S3-backed
>
> Plan before 4.1.0.
>
>> Secondary Storage feature. Looking at this branch, the work done to support
>> S3 does not appear to compatible with the new storage architecture, and I
>> don't think there is enough time before 31 Jan 2013 to retrofit. I also have
>
> The existing storage code on master will not be changed, as the most of our changes on javelin branch are in the fresh new maven projects.
>
>> design concerns which I raise on a separate thread.
>
>
> I'd like to know your comments on the design.
>
>>
>> Thanks,
>> -John
>>
>> On Jan 8, 2013, at 12:08 PM, Alex Huang <Al...@citrix.com> wrote:
>>
>>>> The problem that Howie is talking about is that none of our projects
>>>> are structured in the "standard" maven layout. This isn't just a
>>>> test source issue.
>>>>
>>> I'm saying maven have a way to accommodate for that by specifying exactly
>> where the directory should be in the pom.xml.
>>>
>>> Like I said though, I don't know why it doesn't follow standard layout.
>> Maybe it was just easier to do the maven conversion this way? I think all the
>> directories in javelin has follow the current layout in 4.0 as well. We can
>> make all of the javelin directories follow the standard if there was no clear
>> call on how to layout the structures originally.
>>>
>>> --Alex
>
RE: [MERGE] Merge Javelin branch into master
Posted by Edison Su <Ed...@citrix.com>.
> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com]
> Sent: Tuesday, January 08, 2013 9:13 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [MERGE] Merge Javelin branch into master
>
> All,
>
> Will this merge be pre or post 4.1.0? I am concerned regarding the S3-backed
Plan before 4.1.0.
> Secondary Storage feature. Looking at this branch, the work done to support
> S3 does not appear to compatible with the new storage architecture, and I
> don't think there is enough time before 31 Jan 2013 to retrofit. I also have
The existing storage code on master will not be changed, as the most of our changes on javelin branch are in the fresh new maven projects.
> design concerns which I raise on a separate thread.
I'd like to know your comments on the design.
>
> Thanks,
> -John
>
> On Jan 8, 2013, at 12:08 PM, Alex Huang <Al...@citrix.com> wrote:
>
> >> The problem that Howie is talking about is that none of our projects
> >> are structured in the "standard" maven layout. This isn't just a
> >> test source issue.
> >>
> > I'm saying maven have a way to accommodate for that by specifying exactly
> where the directory should be in the pom.xml.
> >
> > Like I said though, I don't know why it doesn't follow standard layout.
> Maybe it was just easier to do the maven conversion this way? I think all the
> directories in javelin has follow the current layout in 4.0 as well. We can
> make all of the javelin directories follow the standard if there was no clear
> call on how to layout the structures originally.
> >
> > --Alex
Re: [MERGE] Merge Javelin branch into master
Posted by John Burwell <jb...@basho.com>.
All,
Will this merge be pre or post 4.1.0? I am concerned regarding the S3-backed Secondary Storage feature. Looking at this branch, the work done to support S3 does not appear to compatible with the new storage architecture, and I don't think there is enough time before 31 Jan 2013 to retrofit. I also have design concerns which I raise on a separate thread.
Thanks,
-John
On Jan 8, 2013, at 12:08 PM, Alex Huang <Al...@citrix.com> wrote:
>> The problem that Howie is talking about is that none of our projects
>> are structured in the "standard" maven layout. This isn't just a test
>> source issue.
>>
> I'm saying maven have a way to accommodate for that by specifying exactly where the directory should be in the pom.xml.
>
> Like I said though, I don't know why it doesn't follow standard layout. Maybe it was just easier to do the maven conversion this way? I think all the directories in javelin has follow the current layout in 4.0 as well. We can make all of the javelin directories follow the standard if there was no clear call on how to layout the structures originally.
>
> --Alex
Re: [MERGE] Merge Javelin branch into master
Posted by Chip Childers <ch...@sungard.com>.
On Tue, Jan 8, 2013 at 12:08 PM, Alex Huang <Al...@citrix.com> wrote:
>> The problem that Howie is talking about is that none of our projects
>> are structured in the "standard" maven layout. This isn't just a test
>> source issue.
>>
> I'm saying maven have a way to accommodate for that by specifying exactly where the directory should be in the pom.xml.
>
> Like I said though, I don't know why it doesn't follow standard layout. Maybe it was just easier to do the maven conversion this way? I think all the directories in javelin has follow the current layout in 4.0 as well. We can make all of the javelin directories follow the standard if there was no clear call on how to layout the structures originally.
>
> --Alex
This isn't a Javelin branch issue at all... we had decided that we
would convert from ant to maven, and in doing so we would keep the
folder structure intact. I personally don't really care if we use the
"standard" structure or not. I was just clarifying what Howie's point
was, since it had been raised previously on the list.
Re: [MERGE] Merge Javelin branch into master
Posted by Howie Yu <ho...@trend.com.tw>.
Hi Alex
Yes, You are right . I can add testSourceDirectory into pom.xml. I just
want to make sure why not use maven conversion layout ~:)
If I write any unit test for any module , should I still follow the
standard way post my code into review board?
Beside, I find Javelin branch have some error on pom.xml file , can I
report here?
--------------------------
incubator-cloudstack/framework/ipc/pom.xml) has 1 error
Not authorized, ReasonPhrase:Unauthorized. and 'parent.relativePath'
points at wrong local POM @ line 15, column 11 ->
I think the pom.xml of cloud-framework-ipc use wrong parent
The parent pom should be cloudstack-framework
<parent>
<groupId>org.apache.cloudstack</groupId>
<artifactId>cloudstack-framework</artifactId>
<version>4.1.0-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath>
</parent>
Not cloud-engine
<parent>
<groupId>org.apache.cloudstack</groupId>
<artifactId>cloud-engine</artifactId>
<version>4.1.0-SNAPSHOT</version>
<relativePath>../../pom.xml</relativePath>
</parent>
On 13/1/9 上午1:08, "Alex Huang" <Al...@citrix.com> wrote:
>> The problem that Howie is talking about is that none of our projects
>> are structured in the "standard" maven layout. This isn't just a test
>> source issue.
>>
>I'm saying maven have a way to accommodate for that by specifying exactly
>where the directory should be in the pom.xml.
>
>Like I said though, I don't know why it doesn't follow standard layout.
>Maybe it was just easier to do the maven conversion this way? I think
>all the directories in javelin has follow the current layout in 4.0 as
>well. We can make all of the javelin directories follow the standard if
>there was no clear call on how to layout the structures originally.
>
>--Alex
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
RE: [MERGE] Merge Javelin branch into master
Posted by Alex Huang <Al...@citrix.com>.
> The problem that Howie is talking about is that none of our projects
> are structured in the "standard" maven layout. This isn't just a test
> source issue.
>
I'm saying maven have a way to accommodate for that by specifying exactly where the directory should be in the pom.xml.
Like I said though, I don't know why it doesn't follow standard layout. Maybe it was just easier to do the maven conversion this way? I think all the directories in javelin has follow the current layout in 4.0 as well. We can make all of the javelin directories follow the standard if there was no clear call on how to layout the structures originally.
--Alex
Re: [MERGE] Merge Javelin branch into master
Posted by Chip Childers <ch...@sungard.com>.
On Tue, Jan 8, 2013 at 11:58 AM, Alex Huang <Al...@citrix.com> wrote:
> Hi Howie,
>
> Javelin has not merge into master. This is a thread to discuss the merge process and what the community requires before the merge happens.
>
> I believe you can write unit tests today. I don't believe this is related to Spring. You just add <testSourceDirectory> to the pom.xml to indicate where the test directory is. I'm not quite sure why it deviated from the standard maven layout. Perhaps Hugo can shed some light on it?
The problem that Howie is talking about is that none of our projects
are structured in the "standard" maven layout. This isn't just a test
source issue.
> --Alex
>
>> -----Original Message-----
>> From: Howie Yu [mailto:howie_yu@trend.com.tw]
>> Sent: Monday, January 07, 2013 8:59 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [MERGE] Merge Javelin branch into master
>>
>> Hi
>>
>> Since javelin have merge into master and start using spring framework.
>>
>> Is possible also change project layout to formal maven layout?
>>
>> Such as src/main/java/
>> src/main/resources
>> src/test/java
>> src/test/resource
>>
>> Someone new to this community, like me can help to write some unit test
>> for cloudstack module.
>>
>>
>>
>> On 13/1/8 上午12:41, "Alex Huang" <Al...@citrix.com> wrote:
>>
>> >> 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).
>> >
>> >+1 We need to fix all unit tests before merging.
>> >
>> >--Alex
>>
>>
>> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
>> TREND MICRO EMAIL NOTICE
>> The information contained in this email and any attachments is confidential
>> and may be subject to copyright or other intellectual property protection.
>> If you are not the intended recipient, you are not authorized to use or
>> disclose this information, and we request that you notify us by reply mail or
>> telephone and delete the original message from your mail system.
>> </pre></td></tr></table>
>
RE: [MERGE] Merge Javelin branch into master
Posted by Alex Huang <Al...@citrix.com>.
Hi Howie,
Javelin has not merge into master. This is a thread to discuss the merge process and what the community requires before the merge happens.
I believe you can write unit tests today. I don't believe this is related to Spring. You just add <testSourceDirectory> to the pom.xml to indicate where the test directory is. I'm not quite sure why it deviated from the standard maven layout. Perhaps Hugo can shed some light on it?
--Alex
> -----Original Message-----
> From: Howie Yu [mailto:howie_yu@trend.com.tw]
> Sent: Monday, January 07, 2013 8:59 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [MERGE] Merge Javelin branch into master
>
> Hi
>
> Since javelin have merge into master and start using spring framework.
>
> Is possible also change project layout to formal maven layout?
>
> Such as src/main/java/
> src/main/resources
> src/test/java
> src/test/resource
>
> Someone new to this community, like me can help to write some unit test
> for cloudstack module.
>
>
>
> On 13/1/8 上午12:41, "Alex Huang" <Al...@citrix.com> wrote:
>
> >> 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).
> >
> >+1 We need to fix all unit tests before merging.
> >
> >--Alex
>
>
> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
> </pre></td></tr></table>
Re: [MERGE] Merge Javelin branch into master
Posted by Howie Yu <ho...@trend.com.tw>.
Hi
Since javelin have merge into master and start using spring framework.
Is possible also change project layout to formal maven layout?
Such as src/main/java/
src/main/resources
src/test/java
src/test/resource
Someone new to this community, like me can help to write some unit test
for cloudstack module.
On 13/1/8 上午12:41, "Alex Huang" <Al...@citrix.com> wrote:
>> 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).
>
>+1 We need to fix all unit tests before merging.
>
>--Alex
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
RE: [MERGE] Merge Javelin branch into master
Posted by Alex Huang <Al...@citrix.com>.
> 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).
+1 We need to fix all unit tests before merging.
--Alex
Re: [MERGE] Merge Javelin branch into master
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Jan 4, 2013 at 7:34 PM, Kelven Yang <ke...@citrix.com> wrote:
>
>
> On 1/4/13 4:09 PM, "David Nalley" <da...@gnsa.us> wrote:
>
>>On Fri, Jan 4, 2013 at 6:13 PM, Kelven Yang <ke...@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
Re: [MERGE] Merge Javelin branch into master
Posted by Kelven Yang <ke...@citrix.com>.
On 1/4/13 4:09 PM, "David Nalley" <da...@gnsa.us> wrote:
>On Fri, Jan 4, 2013 at 6:13 PM, Kelven Yang <ke...@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.
>
Re: [PROPOSAL] Merge Javelin branch into master
Posted by David Nalley <da...@gnsa.us>.
On Fri, Jan 4, 2013 at 6:13 PM, Kelven Yang <ke...@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
Re: [PROPOSAL] Merge Javelin branch into master
Posted by Kelven Yang <ke...@citrix.com>.
On 1/4/13 3:53 PM, "Marcus Sorensen" <sh...@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" <ke...@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
>>
>>
Re: [PROPOSAL] Merge Javelin branch into master
Posted by Marcus Sorensen <sh...@gmail.com>.
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?
On Jan 4, 2013 4:13 PM, "Kelven Yang" <ke...@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
>
>