On Thu, Jun 5, 2008 at 8:38 AM, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> 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.
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.
> 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/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
