[DISCUSS] Web site (was Rebooting ServiceMix 5)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Web site (was Rebooting ServiceMix 5)

Guillaume Nodet
Administrator
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é <[hidden email]> 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<[hidden email]>  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: [hidden email]
>>> 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<[hidden email]>  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: [hidden email]
>>>>> 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<[hidden email]>
>>>>>>  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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Web site (was Rebooting ServiceMix 5)

Gert Vanthienen
Administrator
L.S.,


About the content: in my mind, most of the content we have, belongs in
the documentation project.  It's only the generic information about
the mailing lists, source code locations, jira, community, ... that
has to go into the website project.  That's about the distinction I
tried to make when creating the website project, so most of the
website contents should be there but it sure needs updating and a bit
of restructuring to get it organized.

For the documentation, I would suggest we:
1. keep the information in the wiki around as the documentation for
ServiceMix 3.x (we decided to only do one more release of that a while
ago, so there's no point in investing a lot of time porting the
information)
2. for the time being, focus on the documentation for ServiceMix 4 - I
think the quick start and camel guide are a good start, but we need to
flesh things out to get a good documentation base for the 4.x series
which we will probably be maintaining for a while
3. as soon as we start committing any code for ServiceMix 5, make sure
to document everything right away - I think that's just a habit we
have to grow and I don't mind being the PITA that asks people to add
the docs after every commit, but I really think it's the only way to
ensure that the documentation does not get behind so much that it
needs a lot of work to fill the gap (as we have now with ServiceMix
4.x)

About the website design, ideally I think we would to implement a new
design together with the new contents and make sure we have something
to show off.  While I like both Chris' and Lukasz' designs, they are
pretty sophisticated and we never got around to actually translating
that into a template that's easy enough to tweak and implement by
simple developers (like non-web-designers as myself). BTW, we do have
the PSD file for Lukasz' mockup attached to
https://issues.apache.org/jira/browse/SMX4-731, but there's not HTML
version for that yet.

That's why I created a very simple HTML page and CSS myself in
http://servicemix.apache.org/staging/mockup/index.html (which is
already in the website codebase) - I agree it does not look half as
sophisticated as the other two suggestions, but it still keeps the
overall layout of those two and at least it has the virtue of being
very simple HTML and CSS we can easily work with and include in the
documentation project as well.  Perhaps we can start with something
like this and if anyone fancies adding a bit more eye candy to it,
that would be great obviously!


Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Wed, Jun 29, 2011 at 9:57 AM, Guillaume Nodet <[hidden email]> wrote:

> 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é <[hidden email]> 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<[hidden email]>  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: [hidden email]
>>>> 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<[hidden email]>  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: [hidden email]
>>>>>> 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<[hidden email]>
>>>>>>>  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
>
Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Web site (was Rebooting ServiceMix 5)

Lars Heinemann-3
Gert,

I like your mockup and it will serve well as foundation for further enhancements.


Best regards,
Lars

--------------------------------------

Lars Heinemann
FuseSource
Email: [hidden email]
Web: http://www.fusesource.com
Blog: http://lhein.blogspot.com
Twitter: lhein77



Am 29.06.2011 um 10:16 schrieb Gert Vanthienen:

> L.S.,
>
>
> About the content: in my mind, most of the content we have, belongs in
> the documentation project.  It's only the generic information about
> the mailing lists, source code locations, jira, community, ... that
> has to go into the website project.  That's about the distinction I
> tried to make when creating the website project, so most of the
> website contents should be there but it sure needs updating and a bit
> of restructuring to get it organized.
>
> For the documentation, I would suggest we:
> 1. keep the information in the wiki around as the documentation for
> ServiceMix 3.x (we decided to only do one more release of that a while
> ago, so there's no point in investing a lot of time porting the
> information)
> 2. for the time being, focus on the documentation for ServiceMix 4 - I
> think the quick start and camel guide are a good start, but we need to
> flesh things out to get a good documentation base for the 4.x series
> which we will probably be maintaining for a while
> 3. as soon as we start committing any code for ServiceMix 5, make sure
> to document everything right away - I think that's just a habit we
> have to grow and I don't mind being the PITA that asks people to add
> the docs after every commit, but I really think it's the only way to
> ensure that the documentation does not get behind so much that it
> needs a lot of work to fill the gap (as we have now with ServiceMix
> 4.x)
>
> About the website design, ideally I think we would to implement a new
> design together with the new contents and make sure we have something
> to show off.  While I like both Chris' and Lukasz' designs, they are
> pretty sophisticated and we never got around to actually translating
> that into a template that's easy enough to tweak and implement by
> simple developers (like non-web-designers as myself). BTW, we do have
> the PSD file for Lukasz' mockup attached to
> https://issues.apache.org/jira/browse/SMX4-731, but there's not HTML
> version for that yet.
>
> That's why I created a very simple HTML page and CSS myself in
> http://servicemix.apache.org/staging/mockup/index.html (which is
> already in the website codebase) - I agree it does not look half as
> sophisticated as the other two suggestions, but it still keeps the
> overall layout of those two and at least it has the virtue of being
> very simple HTML and CSS we can easily work with and include in the
> documentation project as well.  Perhaps we can start with something
> like this and if anyone fancies adding a bit more eye candy to it,
> that would be great obviously!
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Wed, Jun 29, 2011 at 9:57 AM, Guillaume Nodet <[hidden email]> wrote:
>> 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é <[hidden email]> 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<[hidden email]>  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: [hidden email]
>>>>> 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<[hidden email]>  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: [hidden email]
>>>>>>> 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<[hidden email]>
>>>>>>>>  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
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Web site (was Rebooting ServiceMix 5)

Guillaume Nodet
Administrator
The template Chris has been using is available at
http://themeforest.net/item/creativeclean-simple-creative-template/122438
I'm not completely sure about the legal stuff though, as if we plan to
include it in the web console or manual, it seems to imply some
restrictions on downstream users, so we'd have to be very careful
about that.  It should be ok for just the web site, but I think having
a consistent theme would be better.

On Wed, Jun 29, 2011 at 10:21, Lars Heinemann <[hidden email]> wrote:

> Gert,
>
> I like your mockup and it will serve well as foundation for further enhancements.
>
>
> Best regards,
> Lars
>
> --------------------------------------
>
> Lars Heinemann
> FuseSource
> Email: [hidden email]
> Web: http://www.fusesource.com
> Blog: http://lhein.blogspot.com
> Twitter: lhein77
>
>
>
> Am 29.06.2011 um 10:16 schrieb Gert Vanthienen:
>
>> L.S.,
>>
>>
>> About the content: in my mind, most of the content we have, belongs in
>> the documentation project.  It's only the generic information about
>> the mailing lists, source code locations, jira, community, ... that
>> has to go into the website project.  That's about the distinction I
>> tried to make when creating the website project, so most of the
>> website contents should be there but it sure needs updating and a bit
>> of restructuring to get it organized.
>>
>> For the documentation, I would suggest we:
>> 1. keep the information in the wiki around as the documentation for
>> ServiceMix 3.x (we decided to only do one more release of that a while
>> ago, so there's no point in investing a lot of time porting the
>> information)
>> 2. for the time being, focus on the documentation for ServiceMix 4 - I
>> think the quick start and camel guide are a good start, but we need to
>> flesh things out to get a good documentation base for the 4.x series
>> which we will probably be maintaining for a while
>> 3. as soon as we start committing any code for ServiceMix 5, make sure
>> to document everything right away - I think that's just a habit we
>> have to grow and I don't mind being the PITA that asks people to add
>> the docs after every commit, but I really think it's the only way to
>> ensure that the documentation does not get behind so much that it
>> needs a lot of work to fill the gap (as we have now with ServiceMix
>> 4.x)
>>
>> About the website design, ideally I think we would to implement a new
>> design together with the new contents and make sure we have something
>> to show off.  While I like both Chris' and Lukasz' designs, they are
>> pretty sophisticated and we never got around to actually translating
>> that into a template that's easy enough to tweak and implement by
>> simple developers (like non-web-designers as myself). BTW, we do have
>> the PSD file for Lukasz' mockup attached to
>> https://issues.apache.org/jira/browse/SMX4-731, but there's not HTML
>> version for that yet.
>>
>> That's why I created a very simple HTML page and CSS myself in
>> http://servicemix.apache.org/staging/mockup/index.html (which is
>> already in the website codebase) - I agree it does not look half as
>> sophisticated as the other two suggestions, but it still keeps the
>> overall layout of those two and at least it has the virtue of being
>> very simple HTML and CSS we can easily work with and include in the
>> documentation project as well.  Perhaps we can start with something
>> like this and if anyone fancies adding a bit more eye candy to it,
>> that would be great obviously!
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> On Wed, Jun 29, 2011 at 9:57 AM, Guillaume Nodet <[hidden email]> wrote:
>>> 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é <[hidden email]> 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<[hidden email]>  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: [hidden email]
>>>>>> 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<[hidden email]>  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: [hidden email]
>>>>>>>> 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<[hidden email]>
>>>>>>>>>  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
>>>
>
>



--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Web site (was Rebooting ServiceMix 5)

Gert Vanthienen
Administrator
L.S.,


I think a consistent look and feel is important indeed, so if we want
to keep using that template, we probably have to run it by
[hidden email].

Another option could be that we start with a simple HTML/CSS and build
the new look and feel the same way as we do with the rest of our
software, incrementally and by adding features/eye candy/... while we
go.  My own little mockup would be one candidate obviously, but if
someone (with better web design skills) wants to take a stab at
creating a better proposal in the next few days, go for it ;)  I think
the main point would be to get something nice and simple to implement
in the site/docs/webconsole done that can serve as the foundation for
building the new look and feel.


Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Fri, Jul 1, 2011 at 9:59 AM, Guillaume Nodet <[hidden email]> wrote:

> The template Chris has been using is available at
> http://themeforest.net/item/creativeclean-simple-creative-template/122438
> I'm not completely sure about the legal stuff though, as if we plan to
> include it in the web console or manual, it seems to imply some
> restrictions on downstream users, so we'd have to be very careful
> about that.  It should be ok for just the web site, but I think having
> a consistent theme would be better.
>
> On Wed, Jun 29, 2011 at 10:21, Lars Heinemann <[hidden email]> wrote:
>> Gert,
>>
>> I like your mockup and it will serve well as foundation for further enhancements.
>>
>>
>> Best regards,
>> Lars
>>
>> --------------------------------------
>>
>> Lars Heinemann
>> FuseSource
>> Email: [hidden email]
>> Web: http://www.fusesource.com
>> Blog: http://lhein.blogspot.com
>> Twitter: lhein77
>>
>>
>>
>> Am 29.06.2011 um 10:16 schrieb Gert Vanthienen:
>>
>>> L.S.,
>>>
>>>
>>> About the content: in my mind, most of the content we have, belongs in
>>> the documentation project.  It's only the generic information about
>>> the mailing lists, source code locations, jira, community, ... that
>>> has to go into the website project.  That's about the distinction I
>>> tried to make when creating the website project, so most of the
>>> website contents should be there but it sure needs updating and a bit
>>> of restructuring to get it organized.
>>>
>>> For the documentation, I would suggest we:
>>> 1. keep the information in the wiki around as the documentation for
>>> ServiceMix 3.x (we decided to only do one more release of that a while
>>> ago, so there's no point in investing a lot of time porting the
>>> information)
>>> 2. for the time being, focus on the documentation for ServiceMix 4 - I
>>> think the quick start and camel guide are a good start, but we need to
>>> flesh things out to get a good documentation base for the 4.x series
>>> which we will probably be maintaining for a while
>>> 3. as soon as we start committing any code for ServiceMix 5, make sure
>>> to document everything right away - I think that's just a habit we
>>> have to grow and I don't mind being the PITA that asks people to add
>>> the docs after every commit, but I really think it's the only way to
>>> ensure that the documentation does not get behind so much that it
>>> needs a lot of work to fill the gap (as we have now with ServiceMix
>>> 4.x)
>>>
>>> About the website design, ideally I think we would to implement a new
>>> design together with the new contents and make sure we have something
>>> to show off.  While I like both Chris' and Lukasz' designs, they are
>>> pretty sophisticated and we never got around to actually translating
>>> that into a template that's easy enough to tweak and implement by
>>> simple developers (like non-web-designers as myself). BTW, we do have
>>> the PSD file for Lukasz' mockup attached to
>>> https://issues.apache.org/jira/browse/SMX4-731, but there's not HTML
>>> version for that yet.
>>>
>>> That's why I created a very simple HTML page and CSS myself in
>>> http://servicemix.apache.org/staging/mockup/index.html (which is
>>> already in the website codebase) - I agree it does not look half as
>>> sophisticated as the other two suggestions, but it still keeps the
>>> overall layout of those two and at least it has the virtue of being
>>> very simple HTML and CSS we can easily work with and include in the
>>> documentation project as well.  Perhaps we can start with something
>>> like this and if anyone fancies adding a bit more eye candy to it,
>>> that would be great obviously!
>>>
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.blogspot.com/
>>>
>>>
>>>
>>> On Wed, Jun 29, 2011 at 9:57 AM, Guillaume Nodet <[hidden email]> wrote:
>>>> 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é <[hidden email]> 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<[hidden email]>  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: [hidden email]
>>>>>>> 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<[hidden email]>  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: [hidden email]
>>>>>>>>> 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<[hidden email]>
>>>>>>>>>>  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
>>>>
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Web site (was Rebooting ServiceMix 5)

Charles Moulliard
Hi,

I will prepare tomorrow a HTML/CSS + javascript template based on
Lukas proposition https://issues.apache.org/jira/browse/SMX4-731 that
we can easily integrate on Apache server.

Hi Luke,

Can you provide us the code source of your PSD document that you
provide in SMX4-731 ? Is it possible to make some small modifications
?

Regards,

Charles Moulliard

Apache Committer

Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard



On Tue, Jul 12, 2011 at 10:37 PM, Gert Vanthienen
<[hidden email]> wrote:

> L.S.,
>
>
> I think a consistent look and feel is important indeed, so if we want
> to keep using that template, we probably have to run it by
> [hidden email].
>
> Another option could be that we start with a simple HTML/CSS and build
> the new look and feel the same way as we do with the rest of our
> software, incrementally and by adding features/eye candy/... while we
> go.  My own little mockup would be one candidate obviously, but if
> someone (with better web design skills) wants to take a stab at
> creating a better proposal in the next few days, go for it ;)  I think
> the main point would be to get something nice and simple to implement
> in the site/docs/webconsole done that can serve as the foundation for
> building the new look and feel.
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Fri, Jul 1, 2011 at 9:59 AM, Guillaume Nodet <[hidden email]> wrote:
>> The template Chris has been using is available at
>> http://themeforest.net/item/creativeclean-simple-creative-template/122438
>> I'm not completely sure about the legal stuff though, as if we plan to
>> include it in the web console or manual, it seems to imply some
>> restrictions on downstream users, so we'd have to be very careful
>> about that.  It should be ok for just the web site, but I think having
>> a consistent theme would be better.
>>
>> On Wed, Jun 29, 2011 at 10:21, Lars Heinemann <[hidden email]> wrote:
>>> Gert,
>>>
>>> I like your mockup and it will serve well as foundation for further enhancements.
>>>
>>>
>>> Best regards,
>>> Lars
>>>
>>> --------------------------------------
>>>
>>> Lars Heinemann
>>> FuseSource
>>> Email: [hidden email]
>>> Web: http://www.fusesource.com
>>> Blog: http://lhein.blogspot.com
>>> Twitter: lhein77
>>>
>>>
>>>
>>> Am 29.06.2011 um 10:16 schrieb Gert Vanthienen:
>>>
>>>> L.S.,
>>>>
>>>>
>>>> About the content: in my mind, most of the content we have, belongs in
>>>> the documentation project.  It's only the generic information about
>>>> the mailing lists, source code locations, jira, community, ... that
>>>> has to go into the website project.  That's about the distinction I
>>>> tried to make when creating the website project, so most of the
>>>> website contents should be there but it sure needs updating and a bit
>>>> of restructuring to get it organized.
>>>>
>>>> For the documentation, I would suggest we:
>>>> 1. keep the information in the wiki around as the documentation for
>>>> ServiceMix 3.x (we decided to only do one more release of that a while
>>>> ago, so there's no point in investing a lot of time porting the
>>>> information)
>>>> 2. for the time being, focus on the documentation for ServiceMix 4 - I
>>>> think the quick start and camel guide are a good start, but we need to
>>>> flesh things out to get a good documentation base for the 4.x series
>>>> which we will probably be maintaining for a while
>>>> 3. as soon as we start committing any code for ServiceMix 5, make sure
>>>> to document everything right away - I think that's just a habit we
>>>> have to grow and I don't mind being the PITA that asks people to add
>>>> the docs after every commit, but I really think it's the only way to
>>>> ensure that the documentation does not get behind so much that it
>>>> needs a lot of work to fill the gap (as we have now with ServiceMix
>>>> 4.x)
>>>>
>>>> About the website design, ideally I think we would to implement a new
>>>> design together with the new contents and make sure we have something
>>>> to show off.  While I like both Chris' and Lukasz' designs, they are
>>>> pretty sophisticated and we never got around to actually translating
>>>> that into a template that's easy enough to tweak and implement by
>>>> simple developers (like non-web-designers as myself). BTW, we do have
>>>> the PSD file for Lukasz' mockup attached to
>>>> https://issues.apache.org/jira/browse/SMX4-731, but there's not HTML
>>>> version for that yet.
>>>>
>>>> That's why I created a very simple HTML page and CSS myself in
>>>> http://servicemix.apache.org/staging/mockup/index.html (which is
>>>> already in the website codebase) - I agree it does not look half as
>>>> sophisticated as the other two suggestions, but it still keeps the
>>>> overall layout of those two and at least it has the virtue of being
>>>> very simple HTML and CSS we can easily work with and include in the
>>>> documentation project as well.  Perhaps we can start with something
>>>> like this and if anyone fancies adding a bit more eye candy to it,
>>>> that would be great obviously!
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert Vanthienen
>>>> ------------------------
>>>> FuseSource
>>>> Web: http://fusesource.com
>>>> Blog: http://gertvanthienen.blogspot.com/
>>>>
>>>>
>>>>
>>>> On Wed, Jun 29, 2011 at 9:57 AM, Guillaume Nodet <[hidden email]> wrote:
>>>>> 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é <[hidden email]> 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<[hidden email]>  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: [hidden email]
>>>>>>>> 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<[hidden email]>  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: [hidden email]
>>>>>>>>>> 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<[hidden email]>
>>>>>>>>>>>  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
>>>>>
>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Web site (was Rebooting ServiceMix 5)

Jean-Baptiste Onofré
Awesome Charles,

thanks a bunch.

Regards
JB

On 07/13/2011 07:19 AM, Charles Moulliard wrote:

> Hi,
>
> I will prepare tomorrow a HTML/CSS + javascript template based on
> Lukas proposition https://issues.apache.org/jira/browse/SMX4-731 that
> we can easily integrate on Apache server.
>
> Hi Luke,
>
> Can you provide us the code source of your PSD document that you
> provide in SMX4-731 ? Is it possible to make some small modifications
> ?
>
> Regards,
>
> Charles Moulliard
>
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
>
>
>
> On Tue, Jul 12, 2011 at 10:37 PM, Gert Vanthienen
> <[hidden email]>  wrote:
>> L.S.,
>>
>>
>> I think a consistent look and feel is important indeed, so if we want
>> to keep using that template, we probably have to run it by
>> [hidden email].
>>
>> Another option could be that we start with a simple HTML/CSS and build
>> the new look and feel the same way as we do with the rest of our
>> software, incrementally and by adding features/eye candy/... while we
>> go.  My own little mockup would be one candidate obviously, but if
>> someone (with better web design skills) wants to take a stab at
>> creating a better proposal in the next few days, go for it ;)  I think
>> the main point would be to get something nice and simple to implement
>> in the site/docs/webconsole done that can serve as the foundation for
>> building the new look and feel.
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> On Fri, Jul 1, 2011 at 9:59 AM, Guillaume Nodet<[hidden email]>  wrote:
>>> The template Chris has been using is available at
>>> http://themeforest.net/item/creativeclean-simple-creative-template/122438
>>> I'm not completely sure about the legal stuff though, as if we plan to
>>> include it in the web console or manual, it seems to imply some
>>> restrictions on downstream users, so we'd have to be very careful
>>> about that.  It should be ok for just the web site, but I think having
>>> a consistent theme would be better.
>>>
>>> On Wed, Jun 29, 2011 at 10:21, Lars Heinemann<[hidden email]>  wrote:
>>>> Gert,
>>>>
>>>> I like your mockup and it will serve well as foundation for further enhancements.
>>>>
>>>>
>>>> Best regards,
>>>> Lars
>>>>
>>>> --------------------------------------
>>>>
>>>> Lars Heinemann
>>>> FuseSource
>>>> Email: [hidden email]
>>>> Web: http://www.fusesource.com
>>>> Blog: http://lhein.blogspot.com
>>>> Twitter: lhein77
>>>>
>>>>
>>>>
>>>> Am 29.06.2011 um 10:16 schrieb Gert Vanthienen:
>>>>
>>>>> L.S.,
>>>>>
>>>>>
>>>>> About the content: in my mind, most of the content we have, belongs in
>>>>> the documentation project.  It's only the generic information about
>>>>> the mailing lists, source code locations, jira, community, ... that
>>>>> has to go into the website project.  That's about the distinction I
>>>>> tried to make when creating the website project, so most of the
>>>>> website contents should be there but it sure needs updating and a bit
>>>>> of restructuring to get it organized.
>>>>>
>>>>> For the documentation, I would suggest we:
>>>>> 1. keep the information in the wiki around as the documentation for
>>>>> ServiceMix 3.x (we decided to only do one more release of that a while
>>>>> ago, so there's no point in investing a lot of time porting the
>>>>> information)
>>>>> 2. for the time being, focus on the documentation for ServiceMix 4 - I
>>>>> think the quick start and camel guide are a good start, but we need to
>>>>> flesh things out to get a good documentation base for the 4.x series
>>>>> which we will probably be maintaining for a while
>>>>> 3. as soon as we start committing any code for ServiceMix 5, make sure
>>>>> to document everything right away - I think that's just a habit we
>>>>> have to grow and I don't mind being the PITA that asks people to add
>>>>> the docs after every commit, but I really think it's the only way to
>>>>> ensure that the documentation does not get behind so much that it
>>>>> needs a lot of work to fill the gap (as we have now with ServiceMix
>>>>> 4.x)
>>>>>
>>>>> About the website design, ideally I think we would to implement a new
>>>>> design together with the new contents and make sure we have something
>>>>> to show off.  While I like both Chris' and Lukasz' designs, they are
>>>>> pretty sophisticated and we never got around to actually translating
>>>>> that into a template that's easy enough to tweak and implement by
>>>>> simple developers (like non-web-designers as myself). BTW, we do have
>>>>> the PSD file for Lukasz' mockup attached to
>>>>> https://issues.apache.org/jira/browse/SMX4-731, but there's not HTML
>>>>> version for that yet.
>>>>>
>>>>> That's why I created a very simple HTML page and CSS myself in
>>>>> http://servicemix.apache.org/staging/mockup/index.html (which is
>>>>> already in the website codebase) - I agree it does not look half as
>>>>> sophisticated as the other two suggestions, but it still keeps the
>>>>> overall layout of those two and at least it has the virtue of being
>>>>> very simple HTML and CSS we can easily work with and include in the
>>>>> documentation project as well.  Perhaps we can start with something
>>>>> like this and if anyone fancies adding a bit more eye candy to it,
>>>>> that would be great obviously!
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Gert Vanthienen
>>>>> ------------------------
>>>>> FuseSource
>>>>> Web: http://fusesource.com
>>>>> Blog: http://gertvanthienen.blogspot.com/
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 29, 2011 at 9:57 AM, Guillaume Nodet<[hidden email]>  wrote:
>>>>>> 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é<[hidden email]>  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<[hidden email]>    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: [hidden email]
>>>>>>>>> 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<[hidden email]>    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: [hidden email]
>>>>>>>>>>> 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<[hidden email]>
>>>>>>>>>>>>   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
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com