James Tan (ja...@suse.de) wrote: > On 03/13/2013 11:32 AM, Adam Spiers wrote: > >>>"What testing do we run before submitting?" is a key question; thanks for > >>>> >bringing it up. Unfortunately the answer is currently "only whatever > >>>> >we run > >>>> >manually", since Travis only runs on a merged repository containing > >>>> >master > >>>> >from each barclamp repository, due to barclamps currently being unable > >>>> >to run > >>>> >their unit tests standalone. > >>>> >(There are Trello cards to address this, but it's unlikely to get fixed > >>>> >soon.) > >>> > >>>The general pattern we've been following is to have barclamps extend > >>>framework provided classes, and that code currently resides in > >>>crowbar/crowbar_framework... so to get to a point where we can run unit > >>>tests for standalone barclamps will require copying in the framework.... > >>>(chicken, meet egg...). > > The root of all evil here is really the tight coupling we have > between the Crowbar framework itself and the barclamps. We really > need to focus on decoupling them so that can be standalone.
Well, I still don't see how it's possible to decouple them 100%: > >Hmm ... hopefully there is an industry-wide best practice for reusing > >shared code between engines which we can follow? > > A gem? :-) Sure, but each barclamp model will still inherit from the Barclamp base class, for instance, so there is still coupling. I don't think that's a bad thing - it's just a dependency. The thing we really need to eliminate is the need to copy files around. We should be able to take a similar approach to Rails gems for this - when you install a Rails gem, you don't need to manually copy all its models, controllers, views, helpers, assets etc. into your own tree :-) _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
