Thank you for starting this discussion thread Charles, you have brought up a number of important points that we should address.
I will leave the discussion of our technical direction to PMC members, however the issue of better communicating about Servicemix I would like to touch upon. In regards to web presence, Jean-Baptiste has already started a re-factoring of our website, viewable here http://servicemix.apache.org/home2.html. There is a discussion thread started to discuss this update project here http://mail-archives.apache.org/mod_mbox/servicemix-dev/201001.mbox/%[email protected]%3e. Servicemix 4 does contain a fair number of demos/examples, perhaps some updates to our documentation is needed to make these more accessible/consistent to users. On a related note, the servicemix page could also link to recent postings by servicemix developers and users regarding best practices, solutions, experiences, etc. I know that I have benefitted greatly by reading examples posted by my fellow developers here. Luckily I know where to find these posts, new and existing users could benefit by being exposed to these sources. >From the point of view of general documentation, as you have pointed out above, smx4 does need an improvement here. The current smx4 page (http://servicemix.apache.org/SMX4/index.html) is not very easy to use from the stand point of "how to install it, start/stop it, debug, install examples,..". It does contain some very good information as is, it can just use some re-organization and extra getting started information. I'd be happy to help dig into expanding some of the documentation in this area. Jamie On Thu, Jan 21, 2010 at 6:30 AM, Charles Moulliard <[email protected]> wrote: > Hi, > > After playing a while with the features list of ServiceMix, NMR, Camel and > Karaf, I have discovered that we have some discrepancies between the > different files. This is really painful for users having to package > solutions and wanting to use a modular solution based on OSGI specification. > > Moreover, I'm convince that if we want that ServiceMix 4 (or Fuse) becomes > an important player in the field of Enterprise Application Server (designed > around OSGI) and including ESB, Web, EJB, JPA, ... containers, it is > absolutely necessary that we improve what is already packaged in ServiceMix > 4 but also the documentation. Without such approach, the future of > Servicemix 4 will be dark compare to what GlassFish v3 / Websphere > Application Server v7 + Aries / Glassfish v3 already propose. > > Action plan: > - Refactor the features file of ServiceMix 4 to include more features (even > if we have to copy/paste them from Karaf like HTTP feature, Spring, > Spring-DM) > - Add support for Blueprint, Aries application to deploy EBA archives > - Add JPA, JTA, ... containers > - Work on documentation to present ServiceMix 4, how to install it, > start/stop it, debug, install examples, ... > > An alternative for J2EE features like EJB, Web Container could be that we > work in collaboration with existing Web Application Servers to integrate > ServiceMix 4 in. In this case, it really depends on the positioning of > ServiceMix 4 / Fuse in the future : > - standalone application server (we depend on people in charge of > infrastructure and so could be seen as a competitor of existing application > server for which resources to administrate them exist and have the > knowledge, ...), > - server embedded in Web Application Server (more visibility, can reduce > project risk, project can be designed using J2EE or OSGI Enterprise > specifications, ...) > - standalone application server providing also J2EE features > > Remark : What I present here comes from discussion that we have had with > Jean-Baptiste Onofré. > > Regards, > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > ***************************** > blog : http://cmoulliard.blogspot.com > twitter : http://twitter.com/cmoulliard > Linkedlin : http://www.linkedin.com/in/charlesmoulliard > > Apache Camel Group : > http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm >
