Quantcast

To servicemix or not to servicemix

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

To servicemix or not to servicemix

Cristiano Costantini
Hi all,

as I'm waiting for Servicemix 4.6.0 to come out because it solves some
problems with the version of some bundles, I was wondering if I should move
to Karaf (2.3.3) instead on using Servicemix as the basis for my
application.

In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
ActiveMQ if I need to implement some specific EIP. I need many dependencies
from the servicemix bundles of wrapped dependencies, but I don't other
ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
blocking release of 4.6.0.

What you suggest me to do?

Thank you!
Cristiano
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Achim Nierbeck
Hi,

use standalone Karaf and use it to build your own custom "Servicemix",
especially since you don't seem to need NMR.

regards, Achim



2014-02-07 Cristiano Costantini <[hidden email]>:

> Hi all,
>
> as I'm waiting for Servicemix 4.6.0 to come out because it solves some
> problems with the version of some bundles, I was wondering if I should move
> to Karaf (2.3.3) instead on using Servicemix as the basis for my
> application.
>
> In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
> ActiveMQ if I need to implement some specific EIP. I need many dependencies
> from the servicemix bundles of wrapped dependencies, but I don't other
> ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
> blocking release of 4.6.0.
>
> What you suggest me to do?
>
> Thank you!
> Cristiano
>



--

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Cristiano Costantini
Thank you very much for your feedback,
I'll really give it a try then.

Regards,
Cristiano


2014-02-07 Achim Nierbeck <[hidden email]>:

> Hi,
>
> use standalone Karaf and use it to build your own custom "Servicemix",
> especially since you don't seem to need NMR.
>
> regards, Achim
>
>
>
> 2014-02-07 Cristiano Costantini <[hidden email]>:
>
> > Hi all,
> >
> > as I'm waiting for Servicemix 4.6.0 to come out because it solves some
> > problems with the version of some bundles, I was wondering if I should
> move
> > to Karaf (2.3.3) instead on using Servicemix as the basis for my
> > application.
> >
> > In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
> > ActiveMQ if I need to implement some specific EIP. I need many
> dependencies
> > from the servicemix bundles of wrapped dependencies, but I don't other
> > ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
> > blocking release of 4.6.0.
> >
> > What you suggest me to do?
> >
> > Thank you!
> > Cristiano
> >
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
> Commiter & Project Lead
> blog <http://notizblog.nierbeck.de/>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

mikek753
In reply to this post by Cristiano Costantini
Hi,

Check this https://github.com/savoirtech/aetos

Michael.

-----Original Message-----
From: Cristiano Costantini
Sent: Friday, February 07, 2014 10:08 AM
To: [hidden email]
Subject: To servicemix or not to servicemix

Hi all,

as I'm waiting for Servicemix 4.6.0 to come out because it solves some
problems with the version of some bundles, I was wondering if I should move
to Karaf (2.3.3) instead on using Servicemix as the basis for my
application.

In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
ActiveMQ if I need to implement some specific EIP. I need many dependencies
from the servicemix bundles of wrapped dependencies, but I don't other
ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
blocking release of 4.6.0.

What you suggest me to do?

Thank you!
Cristiano

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Claus Ibsen-2
In reply to this post by Cristiano Costantini
On Fri, Feb 7, 2014 at 7:08 PM, Cristiano Costantini
<[hidden email]> wrote:

> Hi all,
>
> as I'm waiting for Servicemix 4.6.0 to come out because it solves some
> problems with the version of some bundles, I was wondering if I should move
> to Karaf (2.3.3) instead on using Servicemix as the basis for my
> application.
>
> In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
> ActiveMQ if I need to implement some specific EIP. I need many dependencies
> from the servicemix bundles of wrapped dependencies, but I don't other
> ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
> blocking release of 4.6.0.
>
> What you suggest me to do?
>
> Thank you!
> Cristiano

ServiceMix is a much less active project today than it used to be.
Also most of the work that used to be at SerivceMix is now happening
at Karaf and Camel instead.

Users looking for a single download installation can still find value
in ServiceMix. But its a bit concerning that the project does not do
releases so often.


In my mind ServiceMix is a dying project, and users should take that
into account.

I would point people 2 main ways.

1)
Karaf and then install what they need such as Camel / CXF etc.
Then you can build your own ServiceMix.

2)
fabric8 which is has a lot more to offer.
http://fabric8.io/

certainly for the new era of cloud and managing a lot of containers,
and having a consistent web user interface using hawtio, and much
more.

.. and besides fabric8 you may find value in Apache Karaf Cellar, and
possible other 3rd party projects.



--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: [hidden email]
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Make your Camel applications look hawt, try: http://hawt.io
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Cristiano Costantini
In reply to this post by mikek753
Hi Mike,
I understand that  https://github.com/savoirtech/aetos is a karaf
customized for using just Kararf, Camel, CXF and ActiveMQ, right?
I will check it and if it works this is great and it will really save me a
lot of time!

Thank you!


2014-02-08 8:34 GMT+01:00 Mike K <[hidden email]>:

> Hi,
>
> Check this https://github.com/savoirtech/aetos
>
> Michael.
>
> -----Original Message----- From: Cristiano Costantini Sent: Friday,
> February 07, 2014 10:08 AM To: [hidden email] Subject: To
> servicemix or not to servicemix
> Hi all,
>
> as I'm waiting for Servicemix 4.6.0 to come out because it solves some
> problems with the version of some bundles, I was wondering if I should move
> to Karaf (2.3.3) instead on using Servicemix as the basis for my
> application.
>
> In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
> ActiveMQ if I need to implement some specific EIP. I need many dependencies
> from the servicemix bundles of wrapped dependencies, but I don't other
> ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
> blocking release of 4.6.0.
>
> What you suggest me to do?
>
> Thank you!
> Cristiano
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Cristiano Costantini
In reply to this post by Claus Ibsen-2
Hi Claus, hi all,

anytime I hear of a "dying" project I get worried, especially if like that
one.

But apart ServiceMix Bundles and the precious work continuously being done
by Jean-Baptiste, you are right and I exactly asked this question to
investigate the orientation and understand the feeling of other people on
the community.

I take the opportunity then say my opinion: "ServiceMix" name has its
"marketing" value and I think it is wrong to let it die.
People trust the name "ServiceMix", don't trust a standalone project on
Github with poor description and documentation.

Probably more and more people simply have the same need as me, and if it is
so, then why not to release the next version of it (Major version 5.0.0) as
more lightweight project, with only Camel, CXF and ActiveMQ (maybe like the
link posted by Mike)?
I believe continuing releasing a "ServiceMix" distribution, is good in the
sense that it encourage the adoption of the platform by starters, and it
will be easier to maintain it with less dependencies.
NMR and JBI should split from the main project and either become plugins or
a separate karaf distribution, anyway with its own independent releases and
versions.

Philosophically, it is not bad at all to remove something if its value has
decreased, and remember that "less is more" =>
http://books.google.it/books?hl=it&id=gJrmszNHQV4C&q=less+is+more#v=onepage&q=%22Less%20is%20more.%20(Browning)%22&f=false

What do you think?

Finally I've taken a quick look at fabric8 but honestly I've not understood
how does it relate to ServiceMix: I can basically summarize my needs as the
need a platform to run karaf/servicemix the demos you can find on my github
repositories: https://github.com/cristcost?tab=repositories
But I trust you and I'll take a more accurate look to it to better
understand. Thank you for the link.

Cristiano




2014-02-08 8:42 GMT+01:00 Claus Ibsen <[hidden email]>:

> On Fri, Feb 7, 2014 at 7:08 PM, Cristiano Costantini
> <[hidden email]> wrote:
> > Hi all,
> >
> > as I'm waiting for Servicemix 4.6.0 to come out because it solves some
> > problems with the version of some bundles, I was wondering if I should
> move
> > to Karaf (2.3.3) instead on using Servicemix as the basis for my
> > application.
> >
> > In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
> > ActiveMQ if I need to implement some specific EIP. I need many
> dependencies
> > from the servicemix bundles of wrapped dependencies, but I don't other
> > ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
> > blocking release of 4.6.0.
> >
> > What you suggest me to do?
> >
> > Thank you!
> > Cristiano
>
> ServiceMix is a much less active project today than it used to be.
> Also most of the work that used to be at SerivceMix is now happening
> at Karaf and Camel instead.
>
> Users looking for a single download installation can still find value
> in ServiceMix. But its a bit concerning that the project does not do
> releases so often.
>
>
> In my mind ServiceMix is a dying project, and users should take that
> into account.
>
> I would point people 2 main ways.
>
> 1)
> Karaf and then install what they need such as Camel / CXF etc.
> Then you can build your own ServiceMix.
>
> 2)
> fabric8 which is has a lot more to offer.
> http://fabric8.io/
>
> certainly for the new era of cloud and managing a lot of containers,
> and having a consistent web user interface using hawtio, and much
> more.
>
> .. and besides fabric8 you may find value in Apache Karaf Cellar, and
> possible other 3rd party projects.
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: [hidden email]
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> Make your Camel applications look hawt, try: http://hawt.io
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Claus Ibsen-2
On Sat, Feb 8, 2014 at 9:48 AM, Cristiano Costantini
<[hidden email]> wrote:
> Hi Claus, hi all,
>
> anytime I hear of a "dying" project I get worried, especially if like that
> one.
>

All projects will eventually die. New projects come and go etc.

Apache has its share of dying projects too.
Though the projects usually have to be dead for years before they go
to the attic etc.


> But apart ServiceMix Bundles and the precious work continuously being done
> by Jean-Baptiste, you are right and I exactly asked this question to
> investigate the orientation and understand the feeling of other people on
> the community.
>

Yeah well as said before the main work is happening at Karaf / Camel etc.
In fact Karaf was the ServiceMix Kernel, which was pulled out as a
separate project to allow re-use for others to build containers. That
was a great move, and Karaf has proven itself as a great independent
project.


> I take the opportunity then say my opinion: "ServiceMix" name has its
> "marketing" value and I think it is wrong to let it die.
> People trust the name "ServiceMix", don't trust a standalone project on
> Github with poor description and documentation.
>

Well I dont agree entirely.

ServiceMix has certainly poor documentation, and never updated, and
never maintained.
The web site is never updated, and new releases is not coming out.
Nobody present ServiceMix at conferences, an publishers are not
publishing books on ServieMix etc.

For some people ServiceMix is *JBI* as that is how it got started.
As a JBI implementation.

Also ServiceMix is associated with ESB which in todays modern world
lost its traction.

In total the ServiceMix brand is not up to par anymore.
Though the name is good for googling as you don't get animals in your
search results ;)


> Probably more and more people simply have the same need as me, and if it is
> so, then why not to release the next version of it (Major version 5.0.0) as
> more lightweight project, with only Camel, CXF and ActiveMQ (maybe like the
> link posted by Mike)?

Apache is an open community. So get INVOLVED.
Help the dying project. Improve its documentation, spread the word.
Help cut new releases etc.

Apache is volunteer based and relies on people helping out.


FuseSource used to do Fuse ESB product which was based on Apache ServiceMix.
That product is no longer, and its evolved into JBoss Fuse as the
commercial product.
The only pieces that are used at the ServiceMIx OSGi bundles that
Karaf/Camel users need.
And the legacy JBI module that is @deprecated and to be removed in the future.

fabric8 as the 100% free ASL2 community project with community releases etc.
It may be the same for other companies. I cannot speak on their behalf.



> I believe continuing releasing a "ServiceMix" distribution, is good in the
> sense that it encourage the adoption of the platform by starters, and it
> will be easier to maintain it with less dependencies.
> NMR and JBI should split from the main project and either become plugins or
> a separate karaf distribution, anyway with its own independent releases and
> versions.
>
> Philosophically, it is not bad at all to remove something if its value has
> decreased, and remember that "less is more" =>
> http://books.google.it/books?hl=it&id=gJrmszNHQV4C&q=less+is+more#v=onepage&q=%22Less%20is%20more.%20(Browning)%22&f=false
>
> What do you think?
>

Yeah famous word. But ServiceMix has not evolved in many many years,
and bring hardly any value over either a pure Karaf + pick what you
need distro. Or .. vs something as elaborate as fabric8 which is a
modern integration platform that is cloud ready.




> Finally I've taken a quick look at fabric8 but honestly I've not understood
> how does it relate to ServiceMix: I can basically summarize my needs as the
> need a platform to run karaf/servicemix the demos you can find on my github
> repositories: https://github.com/cristcost?tab=repositories
> But I trust you and I'll take a more accurate look to it to better
> understand. Thank you for the link.
>

Fabric8 is based on Karaf, so its really a Karaf container in the
lower layer, and then the fabric layer on top. You do not need to use
fabric if you dont need too.

You start fabric8 the same way as Karaf, eg such as

===============================

davsclaus:/opt/fabric8-karaf-1.0.0-SNAPSHOT$ bin/karaf
Please wait while Fabric8 is loading...
100% [========================================================================]

______    _          _      _____
|  ___|  | |        (_)    |  _  |
| |_ __ _| |__  _ __ _  ___ \ V /
|  _/ _` | '_ \| '__| |/ __|/ _ \
| || (_| | |_) | |  | | (__| |_| |
\_| \__,_|_.__/|_|  |_|\___\_____/
  Fabric8 Container (1.0.0-SNAPSHOT)
  http://fabric8.io/

Type 'help' to get started
and 'help [cmd]' for help on a specific command.
Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown this container.

Open a browser to http://localhost:8181 to access the management console

Create a new Fabric via 'fabric:create'
or join an existing Fabric via 'fabric:join [someUrls]'

Fabric8:karaf@root>

===============================

Notice that the prompt says "karaf@root". The shell in there is just karaf.

PS: There is also bin/fusefabric (which is to be renamed to bin/fabric8).





But Karaf is a great and active maintained project. So then Karaf is
likely what your need.
Everyone loves that project.

But when you need have clustered Camel applications, go to the cloud
or have many nodes to manage, or want to use docker, or want to more
easily setup HA reliable brokers, then ServiceMix/Karaf fall short.

Or when you want to use a web console that can manage all these
projects from the same UI, then fabric8 offers that with hawtio -
though you can just install hawtio as well in Karaf.

.. at that point you may have to look elsewhere.

1) one option is fabric8 - with all that above, and more to come.
2) Karaf has the Cellar sub-project, so that may be something to look
into as well.

Also mind that Karaf and ServiceMix is heavy OSGi dependent. Not
everyone need that, or companies have the time to train their
developers to this new world. They just want to develop integration
applications. Their options today is to not use SerivceMix but
containers like Tomcat / Jetty / JEE servers etc.

What fabirc8 is adding to the table later this year, is that it will
portable runtime layer, which allows to run fabric on Tomcat / JBoss
WildFly / Jetty / Karaf etc. And you can mix and match.



Anyway users who have needs for ServiceMix.
Then its your time to get involved and help this *dying* project, so
its no longer dying.



> Cristiano
>
>
>
>
> 2014-02-08 8:42 GMT+01:00 Claus Ibsen <[hidden email]>:
>
>> On Fri, Feb 7, 2014 at 7:08 PM, Cristiano Costantini
>> <[hidden email]> wrote:
>> > Hi all,
>> >
>> > as I'm waiting for Servicemix 4.6.0 to come out because it solves some
>> > problems with the version of some bundles, I was wondering if I should
>> move
>> > to Karaf (2.3.3) instead on using Servicemix as the basis for my
>> > application.
>> >
>> > In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
>> > ActiveMQ if I need to implement some specific EIP. I need many
>> dependencies
>> > from the servicemix bundles of wrapped dependencies, but I don't other
>> > ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
>> > blocking release of 4.6.0.
>> >
>> > What you suggest me to do?
>> >
>> > Thank you!
>> > Cristiano
>>
>> ServiceMix is a much less active project today than it used to be.
>> Also most of the work that used to be at SerivceMix is now happening
>> at Karaf and Camel instead.
>>
>> Users looking for a single download installation can still find value
>> in ServiceMix. But its a bit concerning that the project does not do
>> releases so often.
>>
>>
>> In my mind ServiceMix is a dying project, and users should take that
>> into account.
>>
>> I would point people 2 main ways.
>>
>> 1)
>> Karaf and then install what they need such as Camel / CXF etc.
>> Then you can build your own ServiceMix.
>>
>> 2)
>> fabric8 which is has a lot more to offer.
>> http://fabric8.io/
>>
>> certainly for the new era of cloud and managing a lot of containers,
>> and having a consistent web user interface using hawtio, and much
>> more.
>>
>> .. and besides fabric8 you may find value in Apache Karaf Cellar, and
>> possible other 3rd party projects.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: [hidden email]
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>> Make your Camel applications look hawt, try: http://hawt.io
>>



--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: [hidden email]
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Make your Camel applications look hawt, try: http://hawt.io
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Jean-Baptiste Onofré
In reply to this post by Claus Ibsen-2
Hi,

I fully agree with Claus and Achim.

Karaf as the core platform is a good start, that you can extend with
Fabric and other modules (Cellar, Cave, whatever).

If you want a ready to use ESB based on the same layers, you can start
with JBoss Fuse or Talend ESB (both available in opensource and
enterprise version).

Regards
JB


On 02/08/2014 08:42 AM, Claus Ibsen wrote:

> On Fri, Feb 7, 2014 at 7:08 PM, Cristiano Costantini
> <[hidden email]> wrote:
>> Hi all,
>>
>> as I'm waiting for Servicemix 4.6.0 to come out because it solves some
>> problems with the version of some bundles, I was wondering if I should move
>> to Karaf (2.3.3) instead on using Servicemix as the basis for my
>> application.
>>
>> In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
>> ActiveMQ if I need to implement some specific EIP. I need many dependencies
>> from the servicemix bundles of wrapped dependencies, but I don't other
>> ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
>> blocking release of 4.6.0.
>>
>> What you suggest me to do?
>>
>> Thank you!
>> Cristiano
>
> ServiceMix is a much less active project today than it used to be.
> Also most of the work that used to be at SerivceMix is now happening
> at Karaf and Camel instead.
>
> Users looking for a single download installation can still find value
> in ServiceMix. But its a bit concerning that the project does not do
> releases so often.
>
>
> In my mind ServiceMix is a dying project, and users should take that
> into account.
>
> I would point people 2 main ways.
>
> 1)
> Karaf and then install what they need such as Camel / CXF etc.
> Then you can build your own ServiceMix.
>
> 2)
> fabric8 which is has a lot more to offer.
> http://fabric8.io/
>
> certainly for the new era of cloud and managing a lot of containers,
> and having a consistent web user interface using hawtio, and much
> more.
>
> .. and besides fabric8 you may find value in Apache Karaf Cellar, and
> possible other 3rd party projects.
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Claus Ibsen-2
On Sat, Feb 8, 2014 at 4:01 PM, Jean-Baptiste Onofré <[hidden email]> wrote:
> Hi,
>
> I fully agree with Claus and Achim.
>
> Karaf as the core platform is a good start, that you can extend with Fabric
> and other modules (Cellar, Cave, whatever).
>

Yeah I think Karaf really shines as a core container, that can be
customized and tailored to your needs.
Keep Karaf like that and it will go from strength to strength.

> If you want a ready to use ESB based on the same layers, you can start with
> JBoss Fuse or Talend ESB (both available in opensource and enterprise
> version).
>

Yeah shows the versatility of Karaf that it can be tailored into
commercial products and community versions as counter parts. So when
they can do that, you can do it too. I know of companies that does
that to build their own in-house OEM platform with a customized Karaf
as base.



> Regards
> JB
>
>
>
> On 02/08/2014 08:42 AM, Claus Ibsen wrote:
>>
>> On Fri, Feb 7, 2014 at 7:08 PM, Cristiano Costantini
>> <[hidden email]> wrote:
>>>
>>> Hi all,
>>>
>>> as I'm waiting for Servicemix 4.6.0 to come out because it solves some
>>> problems with the version of some bundles, I was wondering if I should
>>> move
>>> to Karaf (2.3.3) instead on using Servicemix as the basis for my
>>> application.
>>>
>>> In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
>>> ActiveMQ if I need to implement some specific EIP. I need many
>>> dependencies
>>> from the servicemix bundles of wrapped dependencies, but I don't other
>>> ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
>>> blocking release of 4.6.0.
>>>
>>> What you suggest me to do?
>>>
>>> Thank you!
>>> Cristiano
>>
>>
>> ServiceMix is a much less active project today than it used to be.
>> Also most of the work that used to be at SerivceMix is now happening
>> at Karaf and Camel instead.
>>
>> Users looking for a single download installation can still find value
>> in ServiceMix. But its a bit concerning that the project does not do
>> releases so often.
>>
>>
>> In my mind ServiceMix is a dying project, and users should take that
>> into account.
>>
>> I would point people 2 main ways.
>>
>> 1)
>> Karaf and then install what they need such as Camel / CXF etc.
>> Then you can build your own ServiceMix.
>>
>> 2)
>> fabric8 which is has a lot more to offer.
>> http://fabric8.io/
>>
>> certainly for the new era of cloud and managing a lot of containers,
>> and having a consistent web user interface using hawtio, and much
>> more.
>>
>> .. and besides fabric8 you may find value in Apache Karaf Cellar, and
>> possible other 3rd party projects.
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com



--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: [hidden email]
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Make your Camel applications look hawt, try: http://hawt.io
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

ksobkowiak
Hi all

I think the ServiceMix community makes a good and important job which
will be still needed. But what do you think about including the features
provided by ServiceMix in Karaf as additional enterprise (or even esb)
features (as the features for jpa provider, jdbc, jndi,....).

Karaf allows to add the Camel, ActiveMQ, CXF (and more other) features
by feature:repo-add command, but the user must still find out which
version of Camel with which version of ActiveMQ will be correctly work
with the current version of Karaf (e.g. 3.0.0). This problem is solved
in SMX which is shipped with the well defined version of each component.
Instead of having such custom distribution like SMX one would prefer to
have some features like karaf-messaging-support, karaf-services-support,
karaf-routing-support  (or at least how-tos or predefined default
versions for feature:repo-add) included in Karaf which allows him to add
the routing, messaging or web service support by installing one or more
features (referencing the Camel, ActiveMQ, CXF,... features in the
proper versions and adding some extensions like the missing connection
factory in the new versions of ActiveMQ) which guarantee the compatible
versions of the components. It would be also nice to have some samples
(which currently are included in SMX) and integration tests.

I think another SMX features like Activiti support are needed not only
in ESB solutions. It could be also part of Karaf enterprise features.

The ServiceMix bundles and spec could also move to Karaf as subprojects
as they provide osgified version of enterprise libraries.

So instead of having one monolithic SMX distribution we would have more
flexible modular Karaf which could be converted into the esb solution by
installing some features or one could easily install only some of the
esb features (e.g. only web services support). It would be also easier
use another version of Camel or other component as "proposed" by Karaf.
One could say, this is one step back, because Karaf was extracted from
SMX and made as small kernel which can be used to build custom
distributions (including SMX) and we want to move SMX features back into
Karaf. But the role of Karaf as a kernel for other distributions
wouldn't be changed. Karaf even plans to have smaller distributions. It
would only extend Karaf by next group of features - esb features. We
would have one code base which have good testes features for esb
compatible with the current Karaf version. I think it should be also
easier to keep the features working with on each next Karaf release (ad
the features would be developed together with Karaf) as upgrading the
SMX distribution to the newer version of Karaf.

Cristiano writes ServiceMix has a marketing value. ServiceMix does not
need to die quickly. It could be still provided as custom distribution
based on the esb features included in Karaf... based on the newest Karaf
version. It could be once re-branded (e.g. as Karaf ESB) which could be
moved into Karaf as next Karaf distribution (alongside the apache-karaf,
apache-karaf-net, apache-karaf-minimal...).

Sorry for my chaotic ideas collected quickly during fever.

Best regards
Krzysztof


On 08.02.2014 17:49, Claus Ibsen wrote:

> On Sat, Feb 8, 2014 at 4:01 PM, Jean-Baptiste Onofré <[hidden email]> wrote:
>> Hi,
>>
>> I fully agree with Claus and Achim.
>>
>> Karaf as the core platform is a good start, that you can extend with Fabric
>> and other modules (Cellar, Cave, whatever).
>>
> Yeah I think Karaf really shines as a core container, that can be
> customized and tailored to your needs.
> Keep Karaf like that and it will go from strength to strength.
>
>> If you want a ready to use ESB based on the same layers, you can start with
>> JBoss Fuse or Talend ESB (both available in opensource and enterprise
>> version).
>>
> Yeah shows the versatility of Karaf that it can be tailored into
> commercial products and community versions as counter parts. So when
> they can do that, you can do it too. I know of companies that does
> that to build their own in-house OEM platform with a customized Karaf
> as base.
>
>
>
>> Regards
>> JB
>>
>>
>>
>> On 02/08/2014 08:42 AM, Claus Ibsen wrote:
>>> On Fri, Feb 7, 2014 at 7:08 PM, Cristiano Costantini
>>> <[hidden email]> wrote:
>>>> Hi all,
>>>>
>>>> as I'm waiting for Servicemix 4.6.0 to come out because it solves some
>>>> problems with the version of some bundles, I was wondering if I should
>>>> move
>>>> to Karaf (2.3.3) instead on using Servicemix as the basis for my
>>>> application.
>>>>
>>>> In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
>>>> ActiveMQ if I need to implement some specific EIP. I need many
>>>> dependencies
>>>> from the servicemix bundles of wrapped dependencies, but I don't other
>>>> ServiceMix features, especially NMR that I understand from SMX4NMR-319 is
>>>> blocking release of 4.6.0.
>>>>
>>>> What you suggest me to do?
>>>>
>>>> Thank you!
>>>> Cristiano
>>>
>>> ServiceMix is a much less active project today than it used to be.
>>> Also most of the work that used to be at SerivceMix is now happening
>>> at Karaf and Camel instead.
>>>
>>> Users looking for a single download installation can still find value
>>> in ServiceMix. But its a bit concerning that the project does not do
>>> releases so often.
>>>
>>>
>>> In my mind ServiceMix is a dying project, and users should take that
>>> into account.
>>>
>>> I would point people 2 main ways.
>>>
>>> 1)
>>> Karaf and then install what they need such as Camel / CXF etc.
>>> Then you can build your own ServiceMix.
>>>
>>> 2)
>>> fabric8 which is has a lot more to offer.
>>> http://fabric8.io/
>>>
>>> certainly for the new era of cloud and managing a lot of containers,
>>> and having a consistent web user interface using hawtio, and much
>>> more.
>>>
>>> .. and besides fabric8 you may find value in Apache Karaf Cellar, and
>>> possible other 3rd party projects.
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>


--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: [hidden email] <mailto:[hidden email]> |
Twitter: @KSobkowiak
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

To servicemix or not to servicemix

Cristiano Costantini
In reply to this post by Claus Ibsen-2
First of all, thank you for taking your time and discussing it :-)
I started "understanding" ServiceMix only after I had studied your book,
and I always tell to anybody that they need to learn Camel to use
efficiently ServiceMix.


> For some people ServiceMix is *JBI* as that is how it got started.
> As a JBI implementation.
>

I started using ServiceMix at version 4, when Camel had already "replaced"
JBI;

for me ServiceMix means "versions of Camel, Karaf, Spring DM, CXF and
ActiveMQ that works well together " + "useful jars wrapped to bundles" and
maybe some integrated examples, and I believe it is the same for a lot of
people.

The only documentation that matter for ServiceMix is your book, the
documentation of Karaf, books on Spring etc.
In fact, I believe ServiceMix don't need more documentation than links to
the relevant projects.

ServiceMix could be for me simply a karaf feature, but I like to land on
the ServiceMix website and see that someone is monitoring the other
projects for regression and conflicts when used together.



> Apache is an open community. So get INVOLVED.
>

well, surely I don't lack of motivation, but I lack of time and probably a
lot o knowledge about the project :-)

To be honest I lack of interest into NMR. If I do give some type of
contribution, I would do with something I care.

Also, discussing about the project here I believe is an important part of
the contribution someone could do, don't you think?


> Help the dying project. Improve its documentation, spread the word.
>
We try to spread the word:
http://cristcost.github.io/sensormix-slides/index_en.html

Help cut new releases etc.

So why don't we really discuss if NMR etc. can be removed from ServiceMix?

I will first study how to make my custom distribution of Karaf, if I will
still like it, I will try to propose again this approach  ;-)

Regards,
Cristiano
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

mikek753
Hello Cristiano,

I think I was in your shoes about 3 years ago ;-) and sure I understand you
very well.
I'm customer of Apache products and not contributor.
The JBI and NMR and SpringDM were my main concerns at that time.
As result I went with SCA approach, where my OSGi components (bundles) are
connected ether by OSGi services or JMS (AMQ), while data flow is managed by
Camel.
To avoid ClassLoader issues with SpringDM I went with Blueprint (Aries) and
this what I'd recommend you as well.
In the Aetos you can configure exactly what components to use and what
versions.
This is done in short in features.xml (filtered-resources) and later via
featuresBoot (org.apache.karaf.features.cfg ).

I hope you'll find middle ground that works for you ;-)

Michael.

-----Original Message-----
From: Cristiano Costantini
Sent: Saturday, February 08, 2014 1:21 PM
To: [hidden email]
Subject: To servicemix or not to servicemix

First of all, thank you for taking your time and discussing it :-)
I started "understanding" ServiceMix only after I had studied your book,
and I always tell to anybody that they need to learn Camel to use
efficiently ServiceMix.


> For some people ServiceMix is *JBI* as that is how it got started.
> As a JBI implementation.
>

I started using ServiceMix at version 4, when Camel had already "replaced"
JBI;

for me ServiceMix means "versions of Camel, Karaf, Spring DM, CXF and
ActiveMQ that works well together " + "useful jars wrapped to bundles" and
maybe some integrated examples, and I believe it is the same for a lot of
people.

The only documentation that matter for ServiceMix is your book, the
documentation of Karaf, books on Spring etc.
In fact, I believe ServiceMix don't need more documentation than links to
the relevant projects.

ServiceMix could be for me simply a karaf feature, but I like to land on
the ServiceMix website and see that someone is monitoring the other
projects for regression and conflicts when used together.



> Apache is an open community. So get INVOLVED.
>

well, surely I don't lack of motivation, but I lack of time and probably a
lot o knowledge about the project :-)

To be honest I lack of interest into NMR. If I do give some type of
contribution, I would do with something I care.

Also, discussing about the project here I believe is an important part of
the contribution someone could do, don't you think?


> Help the dying project. Improve its documentation, spread the word.
>
We try to spread the word:
http://cristcost.github.io/sensormix-slides/index_en.html

Help cut new releases etc.

So why don't we really discuss if NMR etc. can be removed from ServiceMix?

I will first study how to make my custom distribution of Karaf, if I will
still like it, I will try to propose again this approach  ;-)

Regards,
Cristiano


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Jean-Baptiste Onofré
In reply to this post by ksobkowiak
Hi Krzysztof,

A couple of years ago, I remember a discussion with Guillaume (at
ApacheCon, Vancouver, around a couple of beers ;)), where we dealt about
doing likely what you said in ServiceMix (ServiceMix acting as a
features container). It's why we started to think about something like
Cave (as a Karaf Enterprise Features Repository).

I think your idea is interesting, and it's what I aim for Karaf Cave.
I mean, now, it's not very efficient to have non-core features
"embedded" in Karaf: it's not easy for users to update to new feature
versions without updating to a new Karaf version.
I think that non-core features should be maintained and available
outside of Karaf container itself.

We can see the following Karaf sub-projects:
- Karaf (it's what we have now, the container)
- Bundles (it's the ServiceMix Bundles "moved" as Karaf subproject)
- Features (it's the non-core features, like enterprises, activiti, etc)
- Cellar
- Cave
- EIK
- WebCosnole

Now, regarding the bundles, as it's not directly related to Karaf (it's
more OSGi generic), I wonder if it makes sense to have it in Karaf. I
did a proposal in the past to do it at Felix. Mayben we can imagine to
have a Pax project for the bundles.
For now, I would leave the bundles in ServiceMix.
ServiceMix could still provide:

- bundles and specs
- NMR layer
- a assembly leveraging and gathering features

Regards
JB

On 02/08/2014 07:53 PM, Krzysztof Sobkowiak wrote:

> Hi all
>
> I think the ServiceMix community makes a good and important job which
> will be still needed. But what do you think about including the features
> provided by ServiceMix in Karaf as additional enterprise (or even esb)
> features (as the features for jpa provider, jdbc, jndi,....).
>
> Karaf allows to add the Camel, ActiveMQ, CXF (and more other) features
> by feature:repo-add command, but the user must still find out which
> version of Camel with which version of ActiveMQ will be correctly work
> with the current version of Karaf (e.g. 3.0.0). This problem is solved
> in SMX which is shipped with the well defined version of each component.
> Instead of having such custom distribution like SMX one would prefer to
> have some features like karaf-messaging-support, karaf-services-support,
> karaf-routing-support  (or at least how-tos or predefined default
> versions for feature:repo-add) included in Karaf which allows him to add
> the routing, messaging or web service support by installing one or more
> features (referencing the Camel, ActiveMQ, CXF,... features in the
> proper versions and adding some extensions like the missing connection
> factory in the new versions of ActiveMQ) which guarantee the compatible
> versions of the components. It would be also nice to have some samples
> (which currently are included in SMX) and integration tests.
>
> I think another SMX features like Activiti support are needed not only
> in ESB solutions. It could be also part of Karaf enterprise features.
>
> The ServiceMix bundles and spec could also move to Karaf as subprojects
> as they provide osgified version of enterprise libraries.
>
> So instead of having one monolithic SMX distribution we would have more
> flexible modular Karaf which could be converted into the esb solution by
> installing some features or one could easily install only some of the
> esb features (e.g. only web services support). It would be also easier
> use another version of Camel or other component as "proposed" by Karaf.
> One could say, this is one step back, because Karaf was extracted from
> SMX and made as small kernel which can be used to build custom
> distributions (including SMX) and we want to move SMX features back into
> Karaf. But the role of Karaf as a kernel for other distributions
> wouldn't be changed. Karaf even plans to have smaller distributions. It
> would only extend Karaf by next group of features - esb features. We
> would have one code base which have good testes features for esb
> compatible with the current Karaf version. I think it should be also
> easier to keep the features working with on each next Karaf release (ad
> the features would be developed together with Karaf) as upgrading the
> SMX distribution to the newer version of Karaf.
>
> Cristiano writes ServiceMix has a marketing value. ServiceMix does not
> need to die quickly. It could be still provided as custom distribution
> based on the esb features included in Karaf... based on the newest Karaf
> version. It could be once re-branded (e.g. as Karaf ESB) which could be
> moved into Karaf as next Karaf distribution (alongside the apache-karaf,
> apache-karaf-net, apache-karaf-minimal...).
>
> Sorry for my chaotic ideas collected quickly during fever.
>
> Best regards
> Krzysztof
>
>
> On 08.02.2014 17:49, Claus Ibsen wrote:
>> On Sat, Feb 8, 2014 at 4:01 PM, Jean-Baptiste Onofré <[hidden email]>
>> wrote:
>>> Hi,
>>>
>>> I fully agree with Claus and Achim.
>>>
>>> Karaf as the core platform is a good start, that you can extend with
>>> Fabric
>>> and other modules (Cellar, Cave, whatever).
>>>
>> Yeah I think Karaf really shines as a core container, that can be
>> customized and tailored to your needs.
>> Keep Karaf like that and it will go from strength to strength.
>>
>>> If you want a ready to use ESB based on the same layers, you can
>>> start with
>>> JBoss Fuse or Talend ESB (both available in opensource and enterprise
>>> version).
>>>
>> Yeah shows the versatility of Karaf that it can be tailored into
>> commercial products and community versions as counter parts. So when
>> they can do that, you can do it too. I know of companies that does
>> that to build their own in-house OEM platform with a customized Karaf
>> as base.
>>
>>
>>
>>> Regards
>>> JB
>>>
>>>
>>>
>>> On 02/08/2014 08:42 AM, Claus Ibsen wrote:
>>>> On Fri, Feb 7, 2014 at 7:08 PM, Cristiano Costantini
>>>> <[hidden email]> wrote:
>>>>> Hi all,
>>>>>
>>>>> as I'm waiting for Servicemix 4.6.0 to come out because it solves some
>>>>> problems with the version of some bundles, I was wondering if I should
>>>>> move
>>>>> to Karaf (2.3.3) instead on using Servicemix as the basis for my
>>>>> application.
>>>>>
>>>>> In fact I use Spring, Pax Web, Camel and CXF, and I'll probably need
>>>>> ActiveMQ if I need to implement some specific EIP. I need many
>>>>> dependencies
>>>>> from the servicemix bundles of wrapped dependencies, but I don't other
>>>>> ServiceMix features, especially NMR that I understand from
>>>>> SMX4NMR-319 is
>>>>> blocking release of 4.6.0.
>>>>>
>>>>> What you suggest me to do?
>>>>>
>>>>> Thank you!
>>>>> Cristiano
>>>>
>>>> ServiceMix is a much less active project today than it used to be.
>>>> Also most of the work that used to be at SerivceMix is now happening
>>>> at Karaf and Camel instead.
>>>>
>>>> Users looking for a single download installation can still find value
>>>> in ServiceMix. But its a bit concerning that the project does not do
>>>> releases so often.
>>>>
>>>>
>>>> In my mind ServiceMix is a dying project, and users should take that
>>>> into account.
>>>>
>>>> I would point people 2 main ways.
>>>>
>>>> 1)
>>>> Karaf and then install what they need such as Camel / CXF etc.
>>>> Then you can build your own ServiceMix.
>>>>
>>>> 2)
>>>> fabric8 which is has a lot more to offer.
>>>> http://fabric8.io/
>>>>
>>>> certainly for the new era of cloud and managing a lot of containers,
>>>> and having a consistent web user interface using hawtio, and much
>>>> more.
>>>>
>>>> .. and besides fabric8 you may find value in Apache Karaf Cellar, and
>>>> possible other 3rd party projects.
>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Cristiano Costantini
In reply to this post by ksobkowiak
@Krzysztof

> Karaf allows to add the Camel, ActiveMQ, CXF (and more other) features by
> feature:repo-add command, but the user must still find out which version of
> Camel with which version of ActiveMQ will be correctly work with the
> current version of Karaf (e.g. 3.0.0).

exactly what I care about SMX

The ServiceMix bundles and spec could also move to Karaf as subprojects as
> they provide osgified version of enterprise libraries.

+1


> So instead of having one monolithic SMX distribution we would have more
> flexible modular Karaf which could be converted into the esb solution by
> installing some features or one could easily install only some of the esb
> features (e.g. only web services support).

+1

@Mike K
Thank you, I'll try!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

ksobkowiak
In reply to this post by Jean-Baptiste Onofré
Hi Jean-Baptiste

As long as ServiceMix is not going to die the bundles and specs can be
still part of ServiceMix (until another good place for them will be
found). It makes perhaps no sense to move them into Karaf.

I can remember one discussion somewhere on the mailing list about
extracting the Karaf enterprise features in a separate subproject. This
subproject could  contain the current enterprise and spring features
from Karaf, the features providing the routing, messaging and services
functionality (by referencing the proper well defined versions of Camel,
CXF and ActiveMQ and providing the missing functionalities like the
connection factory as described in previous mail),  the Activiti
integration and many other interesting enterprise features like Karafee.
The features repositories could be referenced in Karaf and included in
Karaf distribution. It is  important that the features should by up to
date and installable in the new Karaf releases and not stay some
releases back. I'd like take for example the latest Karaf 3.x release
(or even snapshot) and make an esb solution installing some features (as
described in my previous mail).

Yeah, ServiceMix 5+ could still exist as an assembly containing the esb
features from Karaf Features subproject. If we had esb features which
are always up to date with Karaf we could just install them on Karaf or
build a new ServiceMix based on a new Karaf version. I tried to upgrade
SMX 5 to Karaf 2.3.3 and the integration tests started to fail
occasionally, but the distribution was stable (I think it's rather a
problem with the Scala tests than the upgraded SMX)

The old ServiceMix features like JBI should still live in ServiceMix.
But I think the features will be not included in ServiceMix 5 and later.

Best regards
Krzysztof

On 08.02.2014 22:56, Jean-Baptiste Onofré wrote:

> Hi Krzysztof,
>
> A couple of years ago, I remember a discussion with Guillaume (at
> ApacheCon, Vancouver, around a couple of beers ;)), where we dealt
> about doing likely what you said in ServiceMix (ServiceMix acting as a
> features container). It's why we started to think about something like
> Cave (as a Karaf Enterprise Features Repository).
>
> I think your idea is interesting, and it's what I aim for Karaf Cave.
> I mean, now, it's not very efficient to have non-core features
> "embedded" in Karaf: it's not easy for users to update to new feature
> versions without updating to a new Karaf version.
> I think that non-core features should be maintained and available
> outside of Karaf container itself.
>
> We can see the following Karaf sub-projects:
> - Karaf (it's what we have now, the container)
> - Bundles (it's the ServiceMix Bundles "moved" as Karaf subproject)
> - Features (it's the non-core features, like enterprises, activiti, etc)
> - Cellar
> - Cave
> - EIK
> - WebCosnole
>
> Now, regarding the bundles, as it's not directly related to Karaf
> (it's more OSGi generic), I wonder if it makes sense to have it in
> Karaf. I did a proposal in the past to do it at Felix. Mayben we can
> imagine to have a Pax project for the bundles.
> For now, I would leave the bundles in ServiceMix.
> ServiceMix could still provide:
>
> - bundles and specs
> - NMR layer
> - a assembly leveraging and gathering features
>
> Regards
> JB
>
> On 02/08/2014 07:53 PM, Krzysztof Sobkowiak wrote:
>> Hi all
>>
>> I think the ServiceMix community makes a good and important job which
>> will be still needed. But what do you think about including the features
>> provided by ServiceMix in Karaf as additional enterprise (or even esb)
>> features (as the features for jpa provider, jdbc, jndi,....).
>>
>> Karaf allows to add the Camel, ActiveMQ, CXF (and more other) features
>> by feature:repo-add command, but the user must still find out which
>> version of Camel with which version of ActiveMQ will be correctly work
>> with the current version of Karaf (e.g. 3.0.0). This problem is solved
>> in SMX which is shipped with the well defined version of each component.
>> Instead of having such custom distribution like SMX one would prefer to
>> have some features like karaf-messaging-support, karaf-services-support,
>> karaf-routing-support  (or at least how-tos or predefined default
>> versions for feature:repo-add) included in Karaf which allows him to add
>> the routing, messaging or web service support by installing one or more
>> features (referencing the Camel, ActiveMQ, CXF,... features in the
>> proper versions and adding some extensions like the missing connection
>> factory in the new versions of ActiveMQ) which guarantee the compatible
>> versions of the components. It would be also nice to have some samples
>> (which currently are included in SMX) and integration tests.
>>
>> I think another SMX features like Activiti support are needed not only
>> in ESB solutions. It could be also part of Karaf enterprise features.
>>
>> The ServiceMix bundles and spec could also move to Karaf as subprojects
>> as they provide osgified version of enterprise libraries.
>>
>> So instead of having one monolithic SMX distribution we would have more
>> flexible modular Karaf which could be converted into the esb solution by
>> installing some features or one could easily install only some of the
>> esb features (e.g. only web services support). It would be also easier
>> use another version of Camel or other component as "proposed" by Karaf.
>> One could say, this is one step back, because Karaf was extracted from
>> SMX and made as small kernel which can be used to build custom
>> distributions (including SMX) and we want to move SMX features back into
>> Karaf. But the role of Karaf as a kernel for other distributions
>> wouldn't be changed. Karaf even plans to have smaller distributions. It
>> would only extend Karaf by next group of features - esb features. We
>> would have one code base which have good testes features for esb
>> compatible with the current Karaf version. I think it should be also
>> easier to keep the features working with on each next Karaf release (ad
>> the features would be developed together with Karaf) as upgrading the
>> SMX distribution to the newer version of Karaf.
>>
>> Cristiano writes ServiceMix has a marketing value. ServiceMix does not
>> need to die quickly. It could be still provided as custom distribution
>> based on the esb features included in Karaf... based on the newest Karaf
>> version. It could be once re-branded (e.g. as Karaf ESB) which could be
>> moved into Karaf as next Karaf distribution (alongside the apache-karaf,
>> apache-karaf-net, apache-karaf-minimal...).
>>
>> Sorry for my chaotic ideas collected quickly during fever.
>>
>> Best regards
>> Krzysztof
>>
>>

--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: [hidden email] <mailto:[hidden email]> |
Twitter: @KSobkowiak
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Jean-Baptiste Onofré
Hi,

Yes, it's what I proposed some time ago: extract the non-core features
from Karaf itself (and not ship them with the distributions), and
provide it as a dedicated sub-project.

I will move forward on this with a formal proposal and branch on github.

Regards
JB

On 02/08/2014 11:56 PM, Krzysztof Sobkowiak wrote:

> Hi Jean-Baptiste
>
> As long as ServiceMix is not going to die the bundles and specs can be
> still part of ServiceMix (until another good place for them will be
> found). It makes perhaps no sense to move them into Karaf.
>
> I can remember one discussion somewhere on the mailing list about
> extracting the Karaf enterprise features in a separate subproject. This
> subproject could  contain the current enterprise and spring features
> from Karaf, the features providing the routing, messaging and services
> functionality (by referencing the proper well defined versions of Camel,
> CXF and ActiveMQ and providing the missing functionalities like the
> connection factory as described in previous mail),  the Activiti
> integration and many other interesting enterprise features like Karafee.
> The features repositories could be referenced in Karaf and included in
> Karaf distribution. It is  important that the features should by up to
> date and installable in the new Karaf releases and not stay some
> releases back. I'd like take for example the latest Karaf 3.x release
> (or even snapshot) and make an esb solution installing some features (as
> described in my previous mail).
>
> Yeah, ServiceMix 5+ could still exist as an assembly containing the esb
> features from Karaf Features subproject. If we had esb features which
> are always up to date with Karaf we could just install them on Karaf or
> build a new ServiceMix based on a new Karaf version. I tried to upgrade
> SMX 5 to Karaf 2.3.3 and the integration tests started to fail
> occasionally, but the distribution was stable (I think it's rather a
> problem with the Scala tests than the upgraded SMX)
>
> The old ServiceMix features like JBI should still live in ServiceMix.
> But I think the features will be not included in ServiceMix 5 and later.
>
> Best regards
> Krzysztof
>
> On 08.02.2014 22:56, Jean-Baptiste Onofré wrote:
>> Hi Krzysztof,
>>
>> A couple of years ago, I remember a discussion with Guillaume (at
>> ApacheCon, Vancouver, around a couple of beers ;)), where we dealt
>> about doing likely what you said in ServiceMix (ServiceMix acting as a
>> features container). It's why we started to think about something like
>> Cave (as a Karaf Enterprise Features Repository).
>>
>> I think your idea is interesting, and it's what I aim for Karaf Cave.
>> I mean, now, it's not very efficient to have non-core features
>> "embedded" in Karaf: it's not easy for users to update to new feature
>> versions without updating to a new Karaf version.
>> I think that non-core features should be maintained and available
>> outside of Karaf container itself.
>>
>> We can see the following Karaf sub-projects:
>> - Karaf (it's what we have now, the container)
>> - Bundles (it's the ServiceMix Bundles "moved" as Karaf subproject)
>> - Features (it's the non-core features, like enterprises, activiti, etc)
>> - Cellar
>> - Cave
>> - EIK
>> - WebCosnole
>>
>> Now, regarding the bundles, as it's not directly related to Karaf
>> (it's more OSGi generic), I wonder if it makes sense to have it in
>> Karaf. I did a proposal in the past to do it at Felix. Mayben we can
>> imagine to have a Pax project for the bundles.
>> For now, I would leave the bundles in ServiceMix.
>> ServiceMix could still provide:
>>
>> - bundles and specs
>> - NMR layer
>> - a assembly leveraging and gathering features
>>
>> Regards
>> JB
>>
>> On 02/08/2014 07:53 PM, Krzysztof Sobkowiak wrote:
>>> Hi all
>>>
>>> I think the ServiceMix community makes a good and important job which
>>> will be still needed. But what do you think about including the features
>>> provided by ServiceMix in Karaf as additional enterprise (or even esb)
>>> features (as the features for jpa provider, jdbc, jndi,....).
>>>
>>> Karaf allows to add the Camel, ActiveMQ, CXF (and more other) features
>>> by feature:repo-add command, but the user must still find out which
>>> version of Camel with which version of ActiveMQ will be correctly work
>>> with the current version of Karaf (e.g. 3.0.0). This problem is solved
>>> in SMX which is shipped with the well defined version of each component.
>>> Instead of having such custom distribution like SMX one would prefer to
>>> have some features like karaf-messaging-support, karaf-services-support,
>>> karaf-routing-support  (or at least how-tos or predefined default
>>> versions for feature:repo-add) included in Karaf which allows him to add
>>> the routing, messaging or web service support by installing one or more
>>> features (referencing the Camel, ActiveMQ, CXF,... features in the
>>> proper versions and adding some extensions like the missing connection
>>> factory in the new versions of ActiveMQ) which guarantee the compatible
>>> versions of the components. It would be also nice to have some samples
>>> (which currently are included in SMX) and integration tests.
>>>
>>> I think another SMX features like Activiti support are needed not only
>>> in ESB solutions. It could be also part of Karaf enterprise features.
>>>
>>> The ServiceMix bundles and spec could also move to Karaf as subprojects
>>> as they provide osgified version of enterprise libraries.
>>>
>>> So instead of having one monolithic SMX distribution we would have more
>>> flexible modular Karaf which could be converted into the esb solution by
>>> installing some features or one could easily install only some of the
>>> esb features (e.g. only web services support). It would be also easier
>>> use another version of Camel or other component as "proposed" by Karaf.
>>> One could say, this is one step back, because Karaf was extracted from
>>> SMX and made as small kernel which can be used to build custom
>>> distributions (including SMX) and we want to move SMX features back into
>>> Karaf. But the role of Karaf as a kernel for other distributions
>>> wouldn't be changed. Karaf even plans to have smaller distributions. It
>>> would only extend Karaf by next group of features - esb features. We
>>> would have one code base which have good testes features for esb
>>> compatible with the current Karaf version. I think it should be also
>>> easier to keep the features working with on each next Karaf release (ad
>>> the features would be developed together with Karaf) as upgrading the
>>> SMX distribution to the newer version of Karaf.
>>>
>>> Cristiano writes ServiceMix has a marketing value. ServiceMix does not
>>> need to die quickly. It could be still provided as custom distribution
>>> based on the esb features included in Karaf... based on the newest Karaf
>>> version. It could be once re-branded (e.g. as Karaf ESB) which could be
>>> moved into Karaf as next Karaf distribution (alongside the apache-karaf,
>>> apache-karaf-net, apache-karaf-minimal...).
>>>
>>> Sorry for my chaotic ideas collected quickly during fever.
>>>
>>> Best regards
>>> Krzysztof
>>>
>>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

ksobkowiak
Do you mean, the user should first add the enterprise feature repository
using repo-add command to use the enterprise features (like currently
camel, dosgi, wicket,...)?

On 08.02.2014 23:58, Jean-Baptiste Onofré wrote:

> Hi,
>
> Yes, it's what I proposed some time ago: extract the non-core features
> from Karaf itself (and not ship them with the distributions), and
> provide it as a dedicated sub-project.
>
> I will move forward on this with a formal proposal and branch on github.
>
> Regards
> JB
>

--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: [hidden email] <mailto:[hidden email]> |
Twitter: @KSobkowiak
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

Jean-Baptiste Onofré
Yes, it could like this. We can pre-load some features repositories in
Karaf distribution (using a config file for instance, extending
etc/org.apache.karaf.features.repos.cfg).

Or, it's where Cave could be interesting: Karaf can connect to Cave
repository providing the features.

Regards
JB

On 02/09/2014 12:09 AM, Krzysztof Sobkowiak wrote:

> Do you mean, the user should first add the enterprise feature repository
> using repo-add command to use the enterprise features (like currently
> camel, dosgi, wicket,...)?
>
> On 08.02.2014 23:58, Jean-Baptiste Onofré wrote:
>> Hi,
>>
>> Yes, it's what I proposed some time ago: extract the non-core features
>> from Karaf itself (and not ship them with the distributions), and
>> provide it as a dedicated sub-project.
>>
>> I will move forward on this with a formal proposal and branch on github.
>>
>> Regards
>> JB
>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: To servicemix or not to servicemix

mikek753
Hi,

How would you resolve dependency versions for main components like Camel and
CXF and AMQ that those are aligned?
Is there any easy way to pick up at will Camel version and CXF version
without thinking of what those use inside?

tnx

Michael.

-----Original Message-----
From: Jean-Baptiste Onofré
Sent: Saturday, February 08, 2014 3:12 PM
To: [hidden email]
Subject: Re: To servicemix or not to servicemix

Yes, it could like this. We can pre-load some features repositories in
Karaf distribution (using a config file for instance, extending
etc/org.apache.karaf.features.repos.cfg).

Or, it's where Cave could be interesting: Karaf can connect to Cave
repository providing the features.

Regards
JB

On 02/09/2014 12:09 AM, Krzysztof Sobkowiak wrote:

> Do you mean, the user should first add the enterprise feature repository
> using repo-add command to use the enterprise features (like currently
> camel, dosgi, wicket,...)?
>
> On 08.02.2014 23:58, Jean-Baptiste Onofré wrote:
>> Hi,
>>
>> Yes, it's what I proposed some time ago: extract the non-core features
>> from Karaf itself (and not ship them with the distributions), and
>> provide it as a dedicated sub-project.
>>
>> I will move forward on this with a formal proposal and branch on github.
>>
>> Regards
>> JB
>>
>

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


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

123
Loading...