On Wed, Jun 4, 2008 at 11:29 PM, Chris Custine <[EMAIL PROTECTED]> wrote: > Following up on this old thread, I have started to experiment with > separating the SMX3 components into their own projects locally and I have > some more details to review. If anyone has anything else to add feel free > to add your thoughts. These ideas below are just intended to start the > discussion... > > 1). I have assumed that we would want each component to have its own > trunk/branches/tags structure in SVN in order to do releases for each > component separately. > Example: > -> components > -> bindings > -> servicemix-cxf-bc > -> trunk > -> branches > -> tags > -> servicemix-file > -> trunk > -> branches > -> tags > -> servicemix-ftp > -> trunk > -> branches > -> tags > -> ... > -> serviceengines > -> servicemix-bean > -> trunk > -> branches > -> tags > -> servicemix-camel > -> trunk > -> branches > -> tags > -> servicemix-cxf-se > -> trunk > -> branches > -> tags > -> ...
Yes, I agree with the ideas above. This matches exactly what I've been thinking. > This seems logical in order to avoid creating an entire release of > ServiceMix when all we need is a specific fix for a single component. Does > anyone have specific opinions on this or suggestions for different > names/structure? The only suggestion I have is to shorten the name of serviceengines to engines similar to the way that you've already shortened bindingcomponents to bindings. My goal is to simplify the concepts in the docs as much as possible and I've found through all the consulting and training I've done with ServiceMix that shortening those names helps folks to get over the JBI nomenclature in their minds. > 2). Any change like the first item above breaks the ability to build all of > the components in a single maven build. One way to get around this is to > have a specific module somewhere that uses svn externals to get all > components so that a single build can cover all components. I think this > would primarily be for convenience in testing and for CI builds. I am > thinking that we would only need the trunk of each component. I think that this is easy to work around by creating a separate assembly for whatever we need, e.g., one to build all binding components, another to build all service engines, another to build all components. etc. > 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. 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/
