Yes, improving Camel components where needed is a prerequisite for deprecating the smx ones.
Regards Lars Am 15.10.2010 um 09:38 schrieb Bengt Rodehav: > I think the general direction should still be to use Camel instead of > servicemix components. If possible, it's far better to improve Camel where > features are lacking or not good enough than providing them as a separate > track outside of Camel. Otherwise I think we'll just add to the confusion > instead of providing clear directions for ServiceMix. > > Still not entirely convinced that ServiceMix should "just" be an ESB > although that is of course the primary purpose. Especially when integrating > technology like Aries, I think the scope of ServiceMix could be extended to > a OSGi based platform for enterprise applications. > > /Bengt > > > 2010/10/15 Lars Heinemann <lh...@apache.org> > >> I think it is a good idea to move to a new major version to do all those >> changes. But I would then >> deprecate both SMX3 and SMX4 to start something really new. And I wouldn't >> even advertise those old >> versions on the new homepage but simply go only for the new one. >> Otherwise we will end up maintaining 3 different versions of smx in code >> and documentation. >> >> I agree that Camel has all components SMX has but the question is if they >> are as good as their >> smx pendants. For camel-mail <-> servicemix-mail I would say that the smx >> one has more functionality. >> So I would not blindly thre away our components without checking that >> first. >> >> Regards >> Lars >> >> >> Am 14.10.2010 um 16:35 schrieb Guillaume Nodet: >> >>> I've had an interesting discussion today with jbonofre about ServiceMix >>> future so I think we should get that on the dev list, hence this mail to >>> start the discussion. I've heard more and more people wondering about >> the >>> value in ServiceMix compared to Karaf + Camel for example. I wonder what >>> your feedback is, how you feel about the future of ServiceMix and what we >>> should do as a community. >>> >>> As for my personal opinion, I think ServiceMix has a very strong brand as >> an >>> open source ESB, but since ServiceMix 4.x, people tend to be confused >> about >>> it. I think there are several path forward. >>> The first thing to state is that the JBI spec did not fulfill its >> promises. >>> For various reasons (mostly political I think), the specs has not been >>> backed by enough big vendors. JBI 2.0 will never happen so the JBI spec >> is >>> kinda dead. The second fact is that more and more users tend to start >> new >>> projects directly with Camel for a lot of valid reasons, mainly its ease >> of >>> use and tons of connectors. That does not mean they don't use ServiceMix >> as >>> the runtime, just that they tend to let aside some features such as the >> JBI >>> or NMR layer. >>> Given those facts, I think one possible future would be to officially >>> deprecate the JBI layer and components (i.e. maintaining those for >>> compatibility, but not necessarily add new features) and focus on more >> value >>> added such as better integration with third party projects (Ode, Hise, >>> etc...) and maybe more tooling (monitoring, etc...). >>> >>> Anyway, it's just my personal opinion and feedback, but i'd like to here >>> what other think about that, so that we can move forward. I'm sure there >>> are a lot of different ways for ServiceMix' future, but the most >> important >>> thing to me is to come up with a clear position that we all agree on and >> be >>> in a better position to move forward and bring ServiceMix to the next >> level. >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >> >>
