BTW.. I'd like the get the servicemix-bean component fully figured out and ported to the new structure before we do start copying the rest of the components to avoid having re-merge changes happening to the components in the smx 3 branches.
Regards, Hiram On Fri, Jun 6, 2008 at 12:21 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote: > ok so I got the intial structure started.. see: > > https://svn.apache.org/repos/asf/servicemix/components/engines/ > > please comment if you don't agree with it. It closely follows Chris's > earlier recommendation which did not have many objections. It does > add a new engines-pom module that will hold the parent pom for the > engines plus it will also use svn externals so you can build all the > components in 1 go. > > What do you think? > > Regards, > Hiram > > > On Fri, Jun 6, 2008 at 11:58 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> Well it seems like most folks agree that we need to do per component >> releases.. I think that's lots of work, but at least it will allow >> components to get individually release which in theory should allow >> them to get released at their own pace and hopefully produce more >> frequent releases. >> >> I'm going to start prototyping some of this work in the >> https://svn.apache.org/repos/asf/servicemix/components area. >> >> Regards, >> Hiram >> >> On Fri, Jun 6, 2008 at 10:37 AM, James Strachan >> <[EMAIL PROTECTED]> wrote: >>> If the containers are released separately, it should be trivial to >>> have integration tests for smx3 and smx4 (and multiple versions of >>> each if required) inside a component's build. >>> >>> This seems kinda separate really to the best way of splitting up the >>> directory tree of the components etc >>> >>> 2008/6/5 Bruce Snyder <[EMAIL PROTECTED]>: >>>> On Thu, Jun 5, 2008 at 1:18 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>>> >>>>>>> 3). Because the components are going to be separate from any SMX >>>>>>> version, >>>>>>> we will need some strategy for testing the components against SMX3 or >>>>>>> SMX4 >>>>>>> or both in the same build (I am thinking we could use profiles). The >>>>>>> real >>>>>>> question is how to do this now that the components will live on their >>>>>>> own. >>>>>>> Ideas are welcomed... >>>>>> >>>>>> I've given this some thought and I've come to the conclusion that we >>>>>> need to use mocks. This can be done in one of two ways: >>>>>> >>>>>> 1) Build out more a feature complete mock framework by moving the >>>>>> classes in the servicemix-core component's >>>>>> org.apache.servicemix.tck.mock package to a separate project named >>>>>> servicemix-mock, OR >>>>>> >>>>>> 2) Use EasyMock (http://easymock.org/) to mock all the necessary >>>>>> behavior provided by an embedded SMX container and anything else >>>>>> surrounding it. >>>>>> >>>>>> In the past I've used both of these approaches for various projects >>>>>> and each has its own set of advantages and disadvantages. I lean >>>>>> toward the use of EasyMock because it's more flexible than creating >>>>>> our own mock objects simply because I've found that mock objects are >>>>>> constantly being refactored to account for unforeseen items. I'm gonna >>>>>> start with the EasyMock approach. >>>>> >>>>> I don't really see why we should not continue using the containers for >>>>> unit testing. It would be a major work to remove the references to >>>>> the container, or even to rewrite all the tests using mocks instead of >>>>> the containers. Furthermore, booting smx3 is very fast and >>>>> lightweight. >>>> >>>> Because the unit tests for the components should no longer rely upon >>>> either smx3 or smx4 containers. They need to be individually testable >>>> and we shouldn't need to create separate tests for each component for >>>> smx3 and smx4. Furthermore, starting up/shutting down a container for >>>> each test just simply takes too long as the number of tests grows. >>>> >>>> Bruce >>>> -- >>>> perl -e 'print unpack("u30","D0G)[EMAIL >>>> PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" >>>> );' >>>> >>>> Apache ActiveMQ - http://activemq.org/ >>>> Apache Camel - http://activemq.org/camel/ >>>> Apache ServiceMix - http://servicemix.org/ >>>> Apache Geronimo - http://geronimo.apache.org/ >>>> >>>> Blog: http://bruceblog.org/ >>>> >>> >>> >>> >>> -- >>> James >>> ------- >>> http://macstrac.blogspot.com/ >>> >>> Open Source Integration >>> http://open.iona.com >>> >> >> >> >> -- >> Regards, >> Hiram >> >> Blog: http://hiramchirino.com >> >> Open Source SOA >> http://open.iona.com >> > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > > Open Source SOA > http://open.iona.com > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
