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
