Regarding the webpage design... As already stated I don't like the design of the webpage. It seems to be a duplicate of the Karaf homepage and I can't see that the page is now more easy and clean as we once intended to do.
I'd like to point you to the following design proposals which I think are really awesome looking... http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from ccustine) http://img259.imageshack.us/img259/1718/servicemix46.jpg (from splatch) Shouldn't we go for something like this? Those designs are awesome looking and have a very clear and simple navigation concept. Wdyt? Best regards, Lars -------------------------------------- Lars Heinemann FuseSource Email: lh...@fusesource.com Web: http://www.fusesource.com Blog: http://lhein.blogspot.com Twitter: lhein77 Am 29.06.2011 um 01:39 schrieb Gert Vanthienen: > Guillaume, > > > All this seems to make a lot of sense to me - let's drop the bits that > don't bring any value (any more) and try to add value to the project > by focusing on providing these container-level services to integration > projects. I also like the idea for creating both a Tomcat and a Karaf > based distribution. That way, people can start with the more familiar > WAR deployment in a simple Tomcat container and, as they need the more > advanced features, gently migrate to the full OSGi-goodness of the > Karaf based distribution. > > For the website, I took an initial stab at migrating the relevant bits > of existing website contents to a Scalate/Maven-based project at > https://svn.apache.org/repos/asf/servicemix/website and pushed an > initial copy of the result out to > http://servicemix.apache.org/staging/ so we can start adding content > again there until we're happy enough with the result to promote this > to become the home page. > > Information about the current location/build/... of the documentation > project can be found at > http://servicemix.apache.org/documentation-project.html - we have a > bit of content for ServiceMix 4.x in there already but it still needs > quite some work. For ServiceMix 5.x, we should probably grow the > habit of documenting every single feature the moment we add it to the > codebase right from the start so we can build the documentation right > along with the actual code. > > > Regards, > > Gert Vanthienen > ------------------------ > FuseSource > Web: http://fusesource.com > Blog: http://gertvanthienen.blogspot.com/ > > > > On Mon, Jun 27, 2011 at 5:54 PM, 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 >>
