You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2014/02/08 22:56:18 UTC
Re: To servicemix or not to servicemix
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é <jb...@nanthrax.net>
>> 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
>>>> <cr...@gmail.com> 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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: To servicemix or not to servicemix
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hi Jean-Baptiste
Could you clarify what do you understand to be content of the Enterprise
Features subproject? I understand this project should contain the
feature xml files. But it should also contain additional components
beaing part of the enterprise features (like the bundle with Activiti
configuration or the KarafEE extensions). Is it ok?
Regards
Krzysztof
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
>
> 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
>>>
--
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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: To servicemix or not to servicemix
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Actually, if you take a look in the Camel features descriptor, Camel
references the CXF feature (with version range):
<features name='camel-${project.version}'>
<repository>mvn:org.apache.cxf.karaf/apache-cxf/${cxf-version}/xml/features</repository>
So, Camel already defines the expected CXF version.
The missing part (resolved in ServiceMix) is ActiveMQ (actually, for
ActiveMQ it's the opposite: ActiveMQ features descriptor references
Camel features).
Regards
JB
On 02/09/2014 12:27 AM, Mike K wrote:
> 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: users@servicemix.apache.org
> 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: To servicemix or not to servicemix
Posted by Mike K <mi...@gmail.com>.
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: users@servicemix.apache.org
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é
jbonofre@apache.org
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
Re: To servicemix or not to servicemix
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: To servicemix or not to servicemix
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: To servicemix or not to servicemix
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: To servicemix or not to servicemix
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak