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
