Hi Guillaume, as already discussed, I'm fully agree about all points.
I will add one point: we have to work on the website and doc. I propose to use the Karaf approach using scalate. Gert and I worked on a new style/css. We can leave the wiki as it is and start from scratch for the new doc and website. I will populate the roadmap page. Regards JB ----- Reply message ----- De : "Guillaume Nodet" <gno...@gmail.com> Pour : "dev" <dev@servicemix.apache.org> Objet : [DISCUSS] Rebooting ServiceMix 5 Date : lun., juin 27, 2011 17:54 Last week, I've been discussing with a few committers about the ServiceMix roadmap. So I'd like to communicate those thoughts to a wider audience. We've been discussing already that the value of ServiceMix (which was the JBI layer in ServiceMix 3 and the container side in ServiceMix 4) has moved mostly to Camel and Karaf respectively. The remainining bits are mostly the NMR. However, the value of the NMR is not in the NMR itself, but rather the NMR was supposed to enable various container-level features. However, we haven't really built those features so that the *real* value of the NMR is not that high currently. So, what we've been discussing is to focus on that added value in a more transparent way by tweaking Camel a bit to support global interceptors, so that one could deploy the real routes without having to force the use of a specific transport such as the current NMR. This way, a user could test / develop the Camel routes or take existing Camel routes and deploy them in ServiceMix, thereby transparently enabling a bunch of useful features. We've been thinking about adding message tracing / timing / auditing, sending test messages, security checks, viewing flows, persistent modification of camel routes, camel route versioning, etc... That need to be coupled with a web console similar to the Camel / ActiveMQ web consoles, to actually display all the data to provide useful information for monitoring Camel routes and help diagnosing problems in production for example. There's really nothing magically new here and some of those features were actually part of ServiceMix 3, but without much focus on those and they have always kept a bit on the side. The idea is really to make ServiceMix the best possible container for deploying Camel based integration. Additional things that could be pushed inside ServiceMix 5 would be a Tomcat based container deployment option (for those that don't need OSGi), a new manual similar to what we have in Karaf (maybe reusing parts of it). We'd also need a new website (without the technical doc, as we have for Karaf I think). On the maintenance of the JBI components and NMR/JBI layer, I think we should keep them in smx4. People wanting to deploy those could easily add a pointer to the servicemix 4 features descriptors and deploy the needed features. So we could officially deprecate those and tell users they won't be available in smx5. This also means that there's really not much to reuse from smx4, so smx5 would have its own new and dedicated svn area. FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the coming months, so those are not faithful wishes, but really something I want to start implementing asap. Feedback welcomed! -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
