Yes unfortunately when I did the rebase and pushed the branch, master was broken. So that failing test is not related to Spring and was removed in commit 765f56a02ced44b7d95574f5901e834c799a56fe on master. Is there any way you can ignore the failure.
Darren On Fri, Oct 4, 2013 at 4:13 AM, Prasanna Santhanam <t...@apache.org> wrote: > Hey Darren, the build appears to be broken on spring-modularization. > Actually a test is broken. If fixed I could generate some packages for > testing. > > http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-yumrepo-refresh/3028/console > > On Fri, Oct 04, 2013 at 10:27:55AM +0530, Prasanna Santhanam wrote: >> Thanks. I will first run a baseline against master since we don't have >> one and then one on spring modularization. The baseline against 4.2 >> shows this result: >> >> http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-regression-matrix/252/testReport/ >> >> On Thu, Oct 03, 2013 at 09:19:23AM -0700, Darren Shepherd wrote: >> > This should be fixed on the spring-modularization branch. >> > >> > Darren >> > >> > On Wed, Oct 2, 2013 at 10:05 PM, Prasanna Santhanam <t...@apache.org> >> > wrote: >> > > I switched the test infrastructure on jenkins.buildacloud.org to run >> > > the bvts [1] against master last week. Couple of weeks before that the >> > > simulator [2] tests were switched to run against master. Both are >> > > broken unfortunately and the bvt and checkin tests aren't running. >> > > >> > > I've filed a bug here: >> > > https://issues.apache.org/jira//browse/CLOUDSTACK-4791 >> > > >> > > [1] http://jenkins.buildacloud.org/view/cloudstack-qa/ >> > > [2] http://jenkins.buildacloud.org/view/simulator/ >> > > >> > > Anyone who has access to the jenkins can run the bvts on their desired >> > > branch. Simply login and change the test-yumrepo-refresh job to point >> > > to your branch. Build that to refresh the remote repository with the >> > > packages made from your branch. Then switch test-matrix to point to >> > > the same development branch and fire a build. That's about it. >> > > >> > > On Wed, Oct 02, 2013 at 05:42:54PM -0700, Darren Shepherd wrote: >> > >> Yes agreed. I've extensively tested this, but that is never enough. >> > >> How do I get the BVTs ran against this. Due to the cross cutting >> > >> nature of this I want to get this merged as fast as possible. >> > >> >> > >> Darren >> > >> >> > >> > On Oct 2, 2013, at 4:43 PM, Alex Huang <alex.hu...@citrix.com> wrote: >> > >> > >> > >> > +1 on running the BVT on it. We've been through this one once >> > >> > before. Should be careful. >> > >> > >> > >> > --Alex >> > >> > >> > >> >> -----Original Message----- >> > >> >> From: Kelven Yang [mailto:kelven.y...@citrix.com] >> > >> >> Sent: Wednesday, October 2, 2013 4:39 PM >> > >> >> To: dev@cloudstack.apache.org >> > >> >> Subject: Re: [MERGE] spring-modularization to master - Spring >> > >> >> Modularization >> > >> >> >> > >> >> Darren, >> > >> >> >> > >> >> This looks really nice. A few questions on Spring AOP replacement. >> > >> >> >> > >> >> 1) Spring AOP is proxy-based, the reason we ended up of using >> > >> >> customized >> > >> >> AOP is mainly due to that inside existing CloudStack codebase, we >> > >> >> have many >> > >> >> places that are doing run-time type-casting, the code in these places >> > >> >> assumes a real object that implements all interfaces in the >> > >> >> semantics context. >> > >> >> At the time when I initially converted to Spring, I couldn't ensure >> > >> >> that >> > >> >> switching to proxy-based AOP can have 100% coverage for these >> > >> >> run-time >> > >> >> cases. What is your approach to address this run-time type-casting >> > >> >> issue? >> > >> >> >> > >> >> 2) We've run into a huge-memory footprint issue that may be caused by >> > >> >> conflicts of CGLIB usage in Spring AOP and the CGLIB usage in >> > >> >> CloudStack Dao >> > >> >> layer. Do you have a chance to run a memory analysis in the heap >> > >> >> after >> > >> >> management server is started. >> > >> >> >> > >> >> I might be good to run BVT test on the branch before the merge, could >> > >> >> someone initiate the effort? >> > >> >> >> > >> >> kelven >> > >> >> >> > >> >> >> > >> >> >> > >> >> On 10/2/13 3:48 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> >> > >> >> wrote: >> > >> >> >> > >> >>> Not sure how this works... I would like to merge in the new >> > >> >>> modularized Spring setup to master. There is info on the wiki about >> > >> >>> it >> > >> >>> [1] [2] [3]. The primary change is to break apart the monolithic >> > >> >>> applicationContext.xml and componentContext.xml files such that each >> > >> >>> plugin can maintain and contribute its own configuration. >> > >> >>> >> > >> >>> In addition to breaking up the configuration we no longer use ACS >> > >> >>> custom AOP and it is now fully Spring AOP. >> > >> >>> >> > >> >>> Now adding/removing a plug-in is a matter of just adding a jar to >> > >> >>> the >> > >> >>> classpath (exception being commands.properties, I'll address that >> > >> >>> in a >> > >> >>> different thread). Unfortunately this branch does not have the >> > >> >>> changes >> > >> >>> to package things in different RPMs. So it would be great if >> > >> >>> somebody >> > >> >>> could take up the packaging effort to split out all the plugins into >> > >> >>> different RPMs. >> > >> >>> >> > >> >>> Darren >> > >> >>> >> > >> >>> [1] >> > >> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Modularize+Sp >> > >> >> rin >> > >> >>> g >> > >> >>> [2] >> > >> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug- >> > >> >> ins%2C+Modu >> > >> >>> les >> > >> >>> %2C+and+Extensions >> > >> >>> [3] >> > >> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions >> > >> > >> > > >> > > -- >> > > Prasanna., >> > > >> > > ------------------------ >> > > Powered by BigRock.com >> > > >> >> -- >> Prasanna., >> >> ------------------------ >> Powered by BigRock.com > > -- > Prasanna., > > ------------------------ > Powered by BigRock.com >
