I've just create a svn repository http://svn.apache.org/repos/asf/servicemix/smx5/trunk and a JIRA for a git mirror https://issues.apache.org/jira/browse/INFRA-3736
On Mon, Jun 27, 2011 at 17:54, Guillaume Nodet <gno...@gmail.com> wrote: > 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 > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
