[DISCUSS] Rebooting ServiceMix 5

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

[DISCUSS] Rebooting ServiceMix 5

Guillaume Nodet
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Gert Vanthienen
Administrator
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
>
Regards,

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

Re: [DISCUSS] Rebooting ServiceMix 5

Willem.Jiang
In reply to this post by Guillaume Nodet
Hi Guillaume

I just have a simple question for it.
As you know Karaf is based on OSGi, I don't know how ServiceMix5 can
achieve this without leverage the OSGi? Do I missing something?

On 6/27/11 11:54 PM, Guillaume Nodet wrote:
> 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).


--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Andreas Pieber
Hey Willem,

You can pack Karaf right now into a WAR already and deploy it on an
Tomcat (see [1]).

Kind regards,
Andreas

[1] https://svn.apache.org/repos/asf/karaf/trunk/demos/web/

On Wed, Jun 29, 2011 at 4:18 AM, Willem Jiang <[hidden email]> wrote:

> Hi Guillaume
>
> I just have a simple question for it.
> As you know Karaf is based on OSGi, I don't know how ServiceMix5 can achieve
> this without leverage the OSGi? Do I missing something?
>
> On 6/27/11 11:54 PM, Guillaume Nodet wrote:
>>
>> 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).
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>         http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Gert Vanthienen
Administrator
Andreas, Willem,

Packing up Karaf in Tomcat would be one way to do it, but I think we
can also get away with a more plain Tomcat container for many of the
use cases listed in Guillaume's mail - as long as we have Camel's core
classes in a shared classloader (i.e. in the container's lib folder)
and are able to inject a single dynamically modifiable interceptor
into the Camel route, we can already do a lot of things like auditing,
tracing, ...

There are obviously quite a few things we can only do if we have a
more dynamic runtime environment, but in my mind that's OK because
that way we also have some good, compelling reasons to move people
over to the Karaf runtime version and tell them about all the goodies
of OSGi (we still all love OSGi and Karaf ourselves ;)).  For advanced
use cases, we should definitely guide users towards Karaf, but for a
set of basic things, just using Tomcat and simple WARs may be the
simplest thing that works for them!

Regards,

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



On Wed, Jun 29, 2011 at 4:27 AM, Andreas Pieber <[hidden email]> wrote:

> Hey Willem,
>
> You can pack Karaf right now into a WAR already and deploy it on an
> Tomcat (see [1]).
>
> Kind regards,
> Andreas
>
> [1] https://svn.apache.org/repos/asf/karaf/trunk/demos/web/
>
> On Wed, Jun 29, 2011 at 4:18 AM, Willem Jiang <[hidden email]> wrote:
>> Hi Guillaume
>>
>> I just have a simple question for it.
>> As you know Karaf is based on OSGi, I don't know how ServiceMix5 can achieve
>> this without leverage the OSGi? Do I missing something?
>>
>> On 6/27/11 11:54 PM, Guillaume Nodet wrote:
>>>
>>> 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).
>>
>>
>> --
>> Willem
>> ----------------------------------
>> FuseSource
>> Web: http://www.fusesource.com
>> Blog:    http://willemjiang.blogspot.com (English)
>>         http://jnn.javaeye.com (Chinese)
>> Twitter: willemjiang
>> Weibo: willemjiang
>>
>
Regards,

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

Re: [DISCUSS] Rebooting ServiceMix 5

Freeman-2
Totally agree.

Deploy an OSGi container into Web/servlet container like tomcat  IMHO  
is weird. Users actually needn't deploy one container into another,  
they just need figure out their real  requirement and chose the proper  
container. Moreover, the different classloader mechanism used by  
different containers may bring more trouble if we mix them.

Best Regards
Freeman
On 2011-6-29, at 下午12:57, Gert Vanthienen wrote:

> Andreas, Willem,
>
> Packing up Karaf in Tomcat would be one way to do it, but I think we
> can also get away with a more plain Tomcat container for many of the
> use cases listed in Guillaume's mail - as long as we have Camel's core
> classes in a shared classloader (i.e. in the container's lib folder)
> and are able to inject a single dynamically modifiable interceptor
> into the Camel route, we can already do a lot of things like auditing,
> tracing, ...
>
> There are obviously quite a few things we can only do if we have a
> more dynamic runtime environment, but in my mind that's OK because
> that way we also have some good, compelling reasons to move people
> over to the Karaf runtime version and tell them about all the goodies
> of OSGi (we still all love OSGi and Karaf ourselves ;)).  For advanced
> use cases, we should definitely guide users towards Karaf, but for a
> set of basic things, just using Tomcat and simple WARs may be the
> simplest thing that works for them!
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Wed, Jun 29, 2011 at 4:27 AM, Andreas Pieber <[hidden email]>  
> wrote:
>> Hey Willem,
>>
>> You can pack Karaf right now into a WAR already and deploy it on an
>> Tomcat (see [1]).
>>
>> Kind regards,
>> Andreas
>>
>> [1] https://svn.apache.org/repos/asf/karaf/trunk/demos/web/
>>
>> On Wed, Jun 29, 2011 at 4:18 AM, Willem Jiang  
>> <[hidden email]> wrote:
>>> Hi Guillaume
>>>
>>> I just have a simple question for it.
>>> As you know Karaf is based on OSGi, I don't know how ServiceMix5  
>>> can achieve
>>> this without leverage the OSGi? Do I missing something?
>>>
>>> On 6/27/11 11:54 PM, Guillaume Nodet wrote:
>>>>
>>>> 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).
>>>
>>>
>>> --
>>> Willem
>>> ----------------------------------
>>> FuseSource
>>> Web: http://www.fusesource.com
>>> Blog:    http://willemjiang.blogspot.com (English)
>>>         http://jnn.javaeye.com (Chinese)
>>> Twitter: willemjiang
>>> Weibo: willemjiang
>>>
>>

---------------------------------------------
Freeman Fang

FuseSource
Email:[hidden email]
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com









Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Lars Heinemann-3
In reply to this post by Gert Vanthienen
Regarding the webpage design...

As already stated I don't like the design of the webpage. It seems to be a duplicate of the Karaf homepage
and I can't see that the page is now more easy and clean as we once intended to do.

I'd like to point you to the following design proposals which I think are really awesome looking...

http://www.flickr.com/photos/ccustine/5390898666/sizes/l/    (from ccustine)
http://img259.imageshack.us/img259/1718/servicemix46.jpg    (from splatch)

Shouldn't we go for something like this? Those designs are awesome looking and have a very clear and simple navigation concept.

Wdyt?

Best regards,
Lars

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

Lars Heinemann
FuseSource
Email: [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
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Guillaume Nodet
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Lars Heinemann-3
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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Guillaume Nodet
Administrator
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] Rebooting ServiceMix 5

Jean-Baptiste Onofré
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
>>
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

iocanel
I am really happy to see the rebooting of Service Mix 5.

I agree with most of the points mentioned but I am skeptic about the tomcat
deployment.

I will skip talking about the advantages of such deployment option, since I
consider them obvious to all. I am worried on what it will mean to the pure
OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
like pojosr?).

Any thoughts?

--
*Ioannis Canellos*
*
 http://iocanel.blogspot.com

Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/>  Committer
*
Ioannis Canellos
http://iocanel.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Juan José Vázquez Delgado
In reply to this post by Guillaume Nodet
Hi Guillaume,

I´m glad to hear that news.

On the other hand, I´ve seen you are working in the Activiti project
[1] right now [2]. Are there any plans to include the Activiti BPMN
engine in ServiceMix 5?.

BR,

Juanjo.

[1] http://www.activiti.org/
[2] http://www.activiti.org/team.html


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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Lars Heinemann-3
In reply to this post by iocanel
Hi Ioannis,

deployment to Tomcat is just an option and meant for easy starting to work with SMX.
I think the Karaf based distro will remain the main distro.


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:45 schrieb Ioannis Canellos:

> I am really happy to see the rebooting of Service Mix 5.
>
> I agree with most of the points mentioned but I am skeptic about the tomcat
> deployment.
>
> I will skip talking about the advantages of such deployment option, since I
> consider them obvious to all. I am worried on what it will mean to the pure
> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
> like pojosr?).
>
> Any thoughts?
>
> --
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Geert Schuring
In reply to this post by iocanel
I too have doubts about the Tomcat distribution. The software stack that
ServiceMix consists of is already very complex, and contains all kinds of
frameworks and components that can be used outside ServiceMix or OSGi as
well. In my opinion ServiceMix should focus on providing a consistent, well
documented environment instead of trying to serve as much different ways of
implementation as possible. I think that's an important reason why the
documentation has been so slow and painful for SMX 3 & 4.

I think starting new documenation from scratch for SMX 5 is a very good
idea. Combined with using scalate and storing the documentation in
subversion, we should be able to write version specific and accurate
documentation.

Would it be possible to drop spring entirely and switch to blueprint for SMX
5? That again would simplify the examples and documentation, and would make
SMX 5 more accessible to new users.

Geert Schuring.

2011/6/29 Ioannis Canellos <[hidden email]>

> I am really happy to see the rebooting of Service Mix 5.
>
> I agree with most of the points mentioned but I am skeptic about the tomcat
> deployment.
>
> I will skip talking about the advantages of such deployment option, since I
> consider them obvious to all. I am worried on what it will mean to the pure
> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
> like pojosr?).
>
> Any thoughts?
>
> --
> *Ioannis Canellos*
> *
>  http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/>  Committer
> *
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Jean-Baptiste Onofré
Hi Geert,

I don't think it's a good idea to remove the Spring support in SMX5 as
it's fully supported by Camel.
If an user want to deploy Camel routes defined using Spring DSL, it should.

Of course, we can focus the documentation about the blueprint usage (I
think it's a good idea), but the Spring support should be still there in
SMX5.

Regards
JB


On 06/29/2011 11:14 AM, Geert Schuring wrote:

> I too have doubts about the Tomcat distribution. The software stack that
> ServiceMix consists of is already very complex, and contains all kinds of
> frameworks and components that can be used outside ServiceMix or OSGi asn
> well. In my opinion ServiceMix should focus on providing a consistent, well
> documented environment instead of trying to serve as much different ways of
> implementation as possible. I think that's an important reason why the
> documentation has been so slow and painful for SMX 3&  4.
>
> I think starting new documenation from scratch for SMX 5 is a very good
> idea. Combined with using scalate and storing the documentation in
> subversion, we should be able to write version specific and accurate
> documentation.
>
> Would it be possible to drop spring entirely and switch to blueprint for SMX
> 5? That again would simplify the examples and documentation, and would make
> SMX 5 more accessible to new users.
>
> Geert Schuring.
>
> 2011/6/29 Ioannis Canellos<[hidden email]>
>
>> I am really happy to see the rebooting of Service Mix 5.
>>
>> I agree with most of the points mentioned but I am skeptic about the tomcat
>> deployment.
>>
>> I will skip talking about the advantages of such deployment option, since I
>> consider them obvious to all. I am worried on what it will mean to the pure
>> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a framework
>> like pojosr?).
>>
>> Any thoughts?
>>
>> --
>> *Ioannis Canellos*
>> *
>>   http://iocanel.blogspot.com
>>
>> Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
>> Apache ServiceMix<http://servicemix.apache.org/>   Committer
>> *
>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Guillaume Nodet
Administrator
Providing a way to easily deploy activiti would definitely be a good thing.
I don't think it should part of the default distribution, as I'd like
to keep it as light as possible though.

On Wed, Jun 29, 2011 at 11:32, Jean-Baptiste Onofré <[hidden email]> wrote:

> Hi Geert,
>
> I don't think it's a good idea to remove the Spring support in SMX5 as it's
> fully supported by Camel.
> If an user want to deploy Camel routes defined using Spring DSL, it should.
>
> Of course, we can focus the documentation about the blueprint usage (I think
> it's a good idea), but the Spring support should be still there in SMX5.
>
> Regards
> JB
>
>
> On 06/29/2011 11:14 AM, Geert Schuring wrote:
>>
>> I too have doubts about the Tomcat distribution. The software stack that
>> ServiceMix consists of is already very complex, and contains all kinds of
>> frameworks and components that can be used outside ServiceMix or OSGi asn
>> well. In my opinion ServiceMix should focus on providing a consistent,
>> well
>> documented environment instead of trying to serve as much different ways
>> of
>> implementation as possible. I think that's an important reason why the
>> documentation has been so slow and painful for SMX 3&  4.
>>
>> I think starting new documenation from scratch for SMX 5 is a very good
>> idea. Combined with using scalate and storing the documentation in
>> subversion, we should be able to write version specific and accurate
>> documentation.
>>
>> Would it be possible to drop spring entirely and switch to blueprint for
>> SMX
>> 5? That again would simplify the examples and documentation, and would
>> make
>> SMX 5 more accessible to new users.
>>
>> Geert Schuring.
>>
>> 2011/6/29 Ioannis Canellos<[hidden email]>
>>
>>> I am really happy to see the rebooting of Service Mix 5.
>>>
>>> I agree with most of the points mentioned but I am skeptic about the
>>> tomcat
>>> deployment.
>>>
>>> I will skip talking about the advantages of such deployment option, since
>>> I
>>> consider them obvious to all. I am worried on what it will mean to the
>>> pure
>>> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a
>>> framework
>>> like pojosr?).
>>>
>>> Any thoughts?
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>>  http://iocanel.blogspot.com
>>>
>>> Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
>>> Apache ServiceMix<http://servicemix.apache.org/>   Committer
>>> *
>>>
>>>
>>>
>>
>



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

Re: [DISCUSS] Rebooting ServiceMix 5

Geert Schuring
In reply to this post by Jean-Baptiste Onofré
JB,

The documentation is my main concern, so if we can somehow agree to only
using blueprint in ServiceMix examples that would be great! The current set
of examples shipped with ServiceMix clearly show that trying to work out
examples without a standard way of packaging and a standard DSL increases
the already steep learning curve significantly. Dropping JBI is already a
great step in that direction.

Geert.

2011/6/29 Jean-Baptiste Onofré <[hidden email]>

> Hi Geert,
>
> I don't think it's a good idea to remove the Spring support in SMX5 as it's
> fully supported by Camel.
> If an user want to deploy Camel routes defined using Spring DSL, it should.
>
> Of course, we can focus the documentation about the blueprint usage (I
> think it's a good idea), but the Spring support should be still there in
> SMX5.
>
> Regards
> JB
>
>
>
> On 06/29/2011 11:14 AM, Geert Schuring wrote:
>
>> I too have doubts about the Tomcat distribution. The software stack that
>> ServiceMix consists of is already very complex, and contains all kinds of
>> frameworks and components that can be used outside ServiceMix or OSGi asn
>>
>> well. In my opinion ServiceMix should focus on providing a consistent,
>> well
>> documented environment instead of trying to serve as much different ways
>> of
>> implementation as possible. I think that's an important reason why the
>> documentation has been so slow and painful for SMX 3&  4.
>>
>> I think starting new documenation from scratch for SMX 5 is a very good
>> idea. Combined with using scalate and storing the documentation in
>> subversion, we should be able to write version specific and accurate
>> documentation.
>>
>> Would it be possible to drop spring entirely and switch to blueprint for
>> SMX
>> 5? That again would simplify the examples and documentation, and would
>> make
>> SMX 5 more accessible to new users.
>>
>> Geert Schuring.
>>
>> 2011/6/29 Ioannis Canellos<[hidden email]>
>>
>>  I am really happy to see the rebooting of Service Mix 5.
>>>
>>> I agree with most of the points mentioned but I am skeptic about the
>>> tomcat
>>> deployment.
>>>
>>> I will skip talking about the advantages of such deployment option, since
>>> I
>>> consider them obvious to all. I am worried on what it will mean to the
>>> pure
>>> OSGi deployments (e.g. restrict the usage of OSGi APIs? Use of a
>>> framework
>>> like pojosr?).
>>>
>>> Any thoughts?
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>>  http://iocanel.blogspot.com
>>>
>>> Apache Karaf<http://karaf.apache.org/**>  Committer&  PMC
>>> Apache ServiceMix<http://servicemix.**apache.org/<http://servicemix.apache.org/>>
>>>   Committer
>>> *
>>>
>>>
>>>
>>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Guillaume Nodet
Administrator
In reply to this post by Guillaume Nodet
I've just create a svn repository
   http://svn.apache.org/repos/asf/servicemix/smx5/trunk
and a JIRA for a git mirror
    https://issues.apache.org/jira/browse/INFRA-3736

On Mon, Jun 27, 2011 at 17:54, Guillaume Nodet <[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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Rebooting ServiceMix 5

Jean-Baptiste Onofré
Thanks a bunch,

I saw the svn commit.

Regards
JB

On 06/29/2011 03:11 PM, Guillaume Nodet wrote:

> I've just create a svn repository
>     http://svn.apache.org/repos/asf/servicemix/smx5/trunk
> and a JIRA for a git mirror
>      https://issues.apache.org/jira/browse/INFRA-3736
>
> On Mon, Jun 27, 2011 at 17:54, Guillaume Nodet<[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
>>
>
>
>
123