Moving to a separate thread. I've sent an email to Lukasz asking for the sources of the web site.
On nightly builds, I agree this would be a good idea to have automated deployment of the web site. If hudson can be leveraged for that, it would be awesome. On Wed, Jun 29, 2011 at 09:38, Jean-Baptiste Onofré <[email protected]> wrote: > I like the splatch website design also. > > As we discussed for Karaf, moving the SMX website to use scalate requires > that we have a "nightly" deployment of the website to quickly update the > news section, etc. > > Regards > JB > > On 06/29/2011 09:33 AM, Guillaume Nodet wrote: >> >> If we do the same as Karaf, the scalate based web site mostly consist >> in non technical docs (downloads, community, irc, forums, etc...) and >> all the technical docs are in versioned manuals. >> >> ServiceMix has a particularity though because we have several major >> versions which are really different, so that may affect a bit. >> >> Anyway, I really like the one splatch, so if he can give us the core >> images used in that web page, I'm sure we can make it work with the >> site Gert has worked on. >> >> On Wed, Jun 29, 2011 at 08:15, Lars Heinemann<[email protected]> wrote: >>> >>> Yes, I agree that we first should go for the content. But it's a bit >>> wired as if we don't have so many sub pages as >>> in the current page then we will probably do content for pages which will >>> not be used or in a different form. >>> >>> We should just have some basic idea how the sitemap will look like before >>> flooding in the content. >>> >>> Best regards, >>> Lars >>> >>> -------------------------------------- >>> >>> Lars Heinemann >>> FuseSource >>> Email: [email protected] >>> Web: http://www.fusesource.com >>> Blog: http://lhein.blogspot.com >>> Twitter: lhein77 >>> >>> >>> >>> Am 29.06.2011 um 08:03 schrieb Guillaume Nodet: >>> >>>> I don't have any problems with changing the design, but I just think >>>> that the content is more important than the color >>>> >>>> On Wed, Jun 29, 2011 at 07:39, Lars Heinemann<[email protected]> wrote: >>>>> >>>>> 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. >>>> >>>> Well, if I can slightly object, it's kinda the opposite, as Karaf has >>>> simply reused the ServiceMix design ;-) >>>> >>>>> 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. >>>> >>>> Both looks really good to me, but before switching the css, we need to >>>> get the scalate stuff to work and the content up to date, so that we >>>> can switch to that new stuff asap. >>>> Then, we can propose changes on the pure css stuff (colors, images, >>>> icons etc...) based on the new website. Once we have the >>>> infrastructure in place, we can easily branch or experiment with css >>>> patches. >>>> >>>>> Wdyt? >>>>> >>>>> Best regards, >>>>> Lars >>>>> >>>>> -------------------------------------- >>>>> >>>>> Lars Heinemann >>>>> FuseSource >>>>> Email: [email protected] >>>>> 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<[email protected]> >>>>>> 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 >>> >>> >> >> >> > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
