You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Cristiano Costantini <cr...@gmail.com> on 2014/02/07 19:08:59 UTC
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
Re: To servicemix or not to servicemix
Posted by Cristiano Costantini <cr...@gmail.com>.
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 <mi...@gmail.com>:
> Hi,
>
> Check this https://github.com/savoirtech/aetos
>
> Michael.
>
> -----Original Message----- From: Cristiano Costantini Sent: Friday,
> February 07, 2014 10:08 AM To: users@servicemix.apache.org 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
>
>
Re: To servicemix or not to servicemix
Posted by Mike K <mi...@gmail.com>.
Hi,
Check this https://github.com/savoirtech/aetos
Michael.
-----Original Message-----
From: Cristiano Costantini
Sent: Friday, February 07, 2014 10:08 AM
To: users@servicemix.apache.org
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
Re: To servicemix or not to servicemix
Posted by Jakub Korab <ja...@gmail.com>.
I am completely new to the ServiceMix dev list, but thought that it might
be the right time to join in.
I would like to echo the sentiment that ServiceMix is a worthwhile project.
An off-the-shelf assembly of the plain old Karaf-Camel-CXF-ActiveMQ
integration stack has merit in getting newcomers working with, what is in
all fairness, a big enough stack to get your head around without the
additional vendor niceties. A set of instructions to homecook your own ESB
is a step too far for those looking to download and just get going.
If it were to go away, I think it would be to the detriment of the broader
community working around "Karaf-based ESBs", which isn't anywhere near as
catchy a search term as ServiceMix, which has a lot of mindshare. After
all, it's much easier to say "X is kind of like ServiceMix only with..."
rather than explaining your stack from scratch. If that was it's only
merit, it would still be worthwhile to push forward.
With that having been said, I'd like to throw my hat into the ring to help
push ServiceMix along, whether that be through just assembling the latest
and greatest into SMX4.x or on in working towards a new SMX5.
Cheers,
Jakub
On Mon, Feb 10, 2014 at 2:42 PM, Cristiano Costantini <
cristiano.costantini@gmail.com> wrote:
> Thank you a lot for the intervention Gert, I care this topic.
>
> My (non-binding) opinion is that I am "interested in having an Apache
> project that is solely about combining ActiveMQ, Camel, CXF, Karaf and a
> few other things into a single integration platform distribution" and I add
> that it should be still named "ServiceMix" that, as I said, has a sort of
> marketing and seo indexing value as a landing point for people searching
> for a credible integration platform.
>
>
> If that will be the direction (very simple aggregation of ActiveMQ, Camel,
> CXF, Karaf without JBI and NMR), I can try to do something to contribute.
> I cannot fully commit yet because I don't know if I'm able to achieve the
> expected level of availability and quality, but I'm optimistic on
> availability because at the moment we use ServiceMix at work and I would
> probably be able to combine some efforts, while I can try to join other
> contributors and figure out what is needed to do while they do it.
>
> Of course, if there is someone more competent than me that is willing to
> do, I'll be happy even more and I may focus on other topic (like promoting
> karaf as a platform for web application - I'm kind of studying Karaf as the
> basis for GWT, Spring Security and Spring MVC web applications)
>
> Regards,
> Cristiano
>
>
>
>
> 2014-02-10 14:16 GMT+01:00 Gert Vanthienen <ge...@gmail.com>:
>
> > L.S.,
> >
> >
> > First of all, thank you for starting this discussion! I definitely
> > agree with everything that has already been said on this thread. We
> > have been ignoring the important, key question for far too long on our
> > mailing lists: Is there a community of users that are interested in
> > having an Apache project that is solely about combining ActiveMQ,
> > Camel, CXF, Karaf and a few other things into a single integration
> > platform distribution? That is the real question we have to answer
> > here.
> >
> > I started updating ServiceMix 4.x to the latest version a while ago,
> > but given the large legacy codebase and the number of subprojects that
> > we have, that is quite an undertaking. Apart from the JBI itests
> > issue, we would also have to get the Features project upgrade done and
> > then do all the release. This is why we restarted the ServiceMix 5
> > effort a year ago: to have a single project with just the dependency
> > versions to update and then cut a release would be a really great
> > thing, compared to the amount of work we now have to do.
> >
> > It looks like nobody out here is interested in doing all that work on
> > the 4.x line and from what I read, the jury is still out on what
> > should happen with the ServiceMix 5 effort. There probably is some
> > value in this type of distribution to get people started with the
> > entire stack of projects more easily, without having to resort to
> > vendor-specific solutions like JBoss Fuse, Fabric8, Talend ESB, ...
> > from day one.
> >
> > We really need some people to do the work though. If nobody is
> > able/willing to put in the effort, it might be better to look into
> > finishing up the project with a bit of style instead of letting it
> > slowly die in the background. With a nice announcement, pointing to
> > the appropriate documentation on the Camel, CXF, Karaf, ... websites,
> > we can definitely get the few people that end up on the ServiceMix
> > project website oriented pretty quickly towards a DIY solution
> > starting with a plain Karaf installation.
> >
> > Personally, I'm fine with either solution. I have always personally
> > liked the Apache ServiceMix project, so if there's some interest to
> > keep doing this, I'll gladly help out there. But on the other hand:
> > it's pretty hard to build a community around only a single assembly
> > project, so if there's no real interest, I'll gladly work with
> > everyone else to draft up a nice announcement and point people towards
> > a better solution as well.
> >
> > Not sure what the best way is to decide this. Perhaps start a vote on
> > what to do next? Given the meaning assigned to the different vote
> > options on https://www.apache.org/foundation/voting.html, that might
> > give us a good idea about who is actually willing/able to help out,
> > but I'm open to any suggestions here.
> >
> >
> > Regards and thanks again for getting this discussion in the open,
> >
> > Gert Vanthienen
> >
> >
> > Regards,
> >
> > Gert Vanthienen
> >
> >
> > 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
> >
>
Re: To servicemix or not to servicemix
Posted by Filippo Balicchia <fb...@gmail.com>.
First of all thanks for this discussion,
from my point of view, servicemix should continue
living for reality who needs a minimalist distro in which is possible found
some of the leading actors
like ActiveMQ, CXF and Camel in a single solution.
Ok, if one wants can do it alone ! but found it out of the box in IHMO and
very comfortable.
In servicemix 5 is possible find modules that can used to create solutions
of a certain dignity then
why throw them away ?
As for version 4 by looking at the commits I see that there is still effort.
for the maintenance, so if from users point of view there is no interest
why they keep it?
Probably time spent from core developer to keep it could be used to smx5
whose intent was to
to cut a release more quickly then now.
>From the other point view, if a structure search a esb solution That truly
had value-add.
should necessarily use the products listed in this thread.
This is IMHO
for me is +1 for maintain servicemix brand and servicemix5
Regards
--Filippo
2014-02-10 15:42 GMT+01:00 Cristiano Costantini <
cristiano.costantini@gmail.com>:
> Thank you a lot for the intervention Gert, I care this topic.
>
> My (non-binding) opinion is that I am "interested in having an Apache
> project that is solely about combining ActiveMQ, Camel, CXF, Karaf and a
> few other things into a single integration platform distribution" and I add
> that it should be still named "ServiceMix" that, as I said, has a sort of
> marketing and seo indexing value as a landing point for people searching
> for a credible integration platform.
>
>
> If that will be the direction (very simple aggregation of ActiveMQ, Camel,
> CXF, Karaf without JBI and NMR), I can try to do something to contribute.
> I cannot fully commit yet because I don't know if I'm able to achieve the
> expected level of availability and quality, but I'm optimistic on
> availability because at the moment we use ServiceMix at work and I would
> probably be able to combine some efforts, while I can try to join other
> contributors and figure out what is needed to do while they do it.
>
> Of course, if there is someone more competent than me that is willing to
> do, I'll be happy even more and I may focus on other topic (like promoting
> karaf as a platform for web application - I'm kind of studying Karaf as the
> basis for GWT, Spring Security and Spring MVC web applications)
>
> Regards,
> Cristiano
>
>
>
>
> 2014-02-10 14:16 GMT+01:00 Gert Vanthienen <ge...@gmail.com>:
>
> > L.S.,
> >
> >
> > First of all, thank you for starting this discussion! I definitely
> > agree with everything that has already been said on this thread. We
> > have been ignoring the important, key question for far too long on our
> > mailing lists: Is there a community of users that are interested in
> > having an Apache project that is solely about combining ActiveMQ,
> > Camel, CXF, Karaf and a few other things into a single integration
> > platform distribution? That is the real question we have to answer
> > here.
> >
> > I started updating ServiceMix 4.x to the latest version a while ago,
> > but given the large legacy codebase and the number of subprojects that
> > we have, that is quite an undertaking. Apart from the JBI itests
> > issue, we would also have to get the Features project upgrade done and
> > then do all the release. This is why we restarted the ServiceMix 5
> > effort a year ago: to have a single project with just the dependency
> > versions to update and then cut a release would be a really great
> > thing, compared to the amount of work we now have to do.
> >
> > It looks like nobody out here is interested in doing all that work on
> > the 4.x line and from what I read, the jury is still out on what
> > should happen with the ServiceMix 5 effort. There probably is some
> > value in this type of distribution to get people started with the
> > entire stack of projects more easily, without having to resort to
> > vendor-specific solutions like JBoss Fuse, Fabric8, Talend ESB, ...
> > from day one.
> >
> > We really need some people to do the work though. If nobody is
> > able/willing to put in the effort, it might be better to look into
> > finishing up the project with a bit of style instead of letting it
> > slowly die in the background. With a nice announcement, pointing to
> > the appropriate documentation on the Camel, CXF, Karaf, ... websites,
> > we can definitely get the few people that end up on the ServiceMix
> > project website oriented pretty quickly towards a DIY solution
> > starting with a plain Karaf installation.
> >
> > Personally, I'm fine with either solution. I have always personally
> > liked the Apache ServiceMix project, so if there's some interest to
> > keep doing this, I'll gladly help out there. But on the other hand:
> > it's pretty hard to build a community around only a single assembly
> > project, so if there's no real interest, I'll gladly work with
> > everyone else to draft up a nice announcement and point people towards
> > a better solution as well.
> >
> > Not sure what the best way is to decide this. Perhaps start a vote on
> > what to do next? Given the meaning assigned to the different vote
> > options on https://www.apache.org/foundation/voting.html, that might
> > give us a good idea about who is actually willing/able to help out,
> > but I'm open to any suggestions here.
> >
> >
> > Regards and thanks again for getting this discussion in the open,
> >
> > Gert Vanthienen
> >
> >
> > Regards,
> >
> > Gert Vanthienen
> >
> >
> > 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
> >
>
Re: To servicemix or not to servicemix
Posted by Cristiano Costantini <cr...@gmail.com>.
Thank you a lot for the intervention Gert, I care this topic.
My (non-binding) opinion is that I am "interested in having an Apache
project that is solely about combining ActiveMQ, Camel, CXF, Karaf and a
few other things into a single integration platform distribution" and I add
that it should be still named "ServiceMix" that, as I said, has a sort of
marketing and seo indexing value as a landing point for people searching
for a credible integration platform.
If that will be the direction (very simple aggregation of ActiveMQ, Camel,
CXF, Karaf without JBI and NMR), I can try to do something to contribute.
I cannot fully commit yet because I don't know if I'm able to achieve the
expected level of availability and quality, but I'm optimistic on
availability because at the moment we use ServiceMix at work and I would
probably be able to combine some efforts, while I can try to join other
contributors and figure out what is needed to do while they do it.
Of course, if there is someone more competent than me that is willing to
do, I'll be happy even more and I may focus on other topic (like promoting
karaf as a platform for web application - I'm kind of studying Karaf as the
basis for GWT, Spring Security and Spring MVC web applications)
Regards,
Cristiano
2014-02-10 14:16 GMT+01:00 Gert Vanthienen <ge...@gmail.com>:
> L.S.,
>
>
> First of all, thank you for starting this discussion! I definitely
> agree with everything that has already been said on this thread. We
> have been ignoring the important, key question for far too long on our
> mailing lists: Is there a community of users that are interested in
> having an Apache project that is solely about combining ActiveMQ,
> Camel, CXF, Karaf and a few other things into a single integration
> platform distribution? That is the real question we have to answer
> here.
>
> I started updating ServiceMix 4.x to the latest version a while ago,
> but given the large legacy codebase and the number of subprojects that
> we have, that is quite an undertaking. Apart from the JBI itests
> issue, we would also have to get the Features project upgrade done and
> then do all the release. This is why we restarted the ServiceMix 5
> effort a year ago: to have a single project with just the dependency
> versions to update and then cut a release would be a really great
> thing, compared to the amount of work we now have to do.
>
> It looks like nobody out here is interested in doing all that work on
> the 4.x line and from what I read, the jury is still out on what
> should happen with the ServiceMix 5 effort. There probably is some
> value in this type of distribution to get people started with the
> entire stack of projects more easily, without having to resort to
> vendor-specific solutions like JBoss Fuse, Fabric8, Talend ESB, ...
> from day one.
>
> We really need some people to do the work though. If nobody is
> able/willing to put in the effort, it might be better to look into
> finishing up the project with a bit of style instead of letting it
> slowly die in the background. With a nice announcement, pointing to
> the appropriate documentation on the Camel, CXF, Karaf, ... websites,
> we can definitely get the few people that end up on the ServiceMix
> project website oriented pretty quickly towards a DIY solution
> starting with a plain Karaf installation.
>
> Personally, I'm fine with either solution. I have always personally
> liked the Apache ServiceMix project, so if there's some interest to
> keep doing this, I'll gladly help out there. But on the other hand:
> it's pretty hard to build a community around only a single assembly
> project, so if there's no real interest, I'll gladly work with
> everyone else to draft up a nice announcement and point people towards
> a better solution as well.
>
> Not sure what the best way is to decide this. Perhaps start a vote on
> what to do next? Given the meaning assigned to the different vote
> options on https://www.apache.org/foundation/voting.html, that might
> give us a good idea about who is actually willing/able to help out,
> but I'm open to any suggestions here.
>
>
> Regards and thanks again for getting this discussion in the open,
>
> Gert Vanthienen
>
>
> Regards,
>
> Gert Vanthienen
>
>
> 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
>
Re: To servicemix or not to servicemix
Posted by raulk <ra...@evosent.com>.
Absolutely agree with all the positive comments on this thread!
I tend to consider SMX as a brand rather than simply a project. There's no
project called "Apache ESB" in the ASF, and IMO SMX has earned its
reputation as such over time. Folks know that SMX is the go-to project for
adopting vanilla Apache technology to solve integration problems without
resorting to vendor-specific solutions.
Hell, I would even go so far as to say that the SMX community has the
responsibility to keep the Apache brand alive in the integration market!
Please do count me in for this venture. Off the top of my head, we should
focus on these priorities for SMX5:
* Upgrade individual components to their latest versions. I would go so far
as to upgrade to Karaf 3.0.0; that's what major versions are for (SMX4 =>
SMX5). Perhaps we could do a minor release with Karaf 2.3.3.
* Revamp the website. SMX is a powerful brand, but the current website is
outdated and could do with a facelift. It doesn't convey the power of the
brand. Gert was already working on a preview. I personally love the look and
feel of the Apache Cordova site [1]. The frontpage should be clean, smart,
bold and simple. Frontend development isn't my biggest strength, but I'm
looking for an amateur project to polish my skills. This could be it!
* Define modular strategy of the project. I agree with the ideas posted
around to keep SMX to its bare minimum OOTB (Karaf, Camel, AMQ, CXF) - this
is our foundation. We shouldn't hold up a SMX release because of
non-foundational components, e.g. Activiti integration, Hibernate
integration, etc. IMHO, those should have separate lifecycles, own
versioning and they should be installed via features or via dedicated
shortcut commands (e.g. servicemix:module-install) that get translated into
feature commands.
Regards,
Raúl.
[1] http://cordova.apache.org/
--
View this message in context: http://servicemix.396122.n5.nabble.com/To-servicemix-or-not-to-servicemix-tp5718935p5719065.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: To servicemix or not to servicemix
Posted by Cristiano Costantini <cr...@gmail.com>.
Il lunedì 10 febbraio 2014, Andrew Thorburn <nz...@gmail.com> ha scritto:
>
> The one other thing I would like to add is that I do use the NMR, simply as
> a really easy way to connect two Camel routes in separate bundles without
> the hassle of trying to configure JMS routes
>
Hi Andrew,
I used NMR too but now I use the Camel VM component for the same purpose.
Regards
Re: To servicemix or not to servicemix
Posted by Matt Wendling <mw...@ipass.com>.
Hi,
I'm also somewhat new to Servicemix and I'm finding great value in the
Karaf-camel-CXF-ActiveMq combination. An up to date release with the
latest versions of those projects would be great. I could certainly help
contribute as well
Matt
On Tue, Feb 11, 2014 at 8:56 AM, Cristiano Costantini <
cristiano.costantini@gmail.com> wrote:
> I fully agree with the strategy proposed by Krzysztof ;-)
>
> Il martedì 11 febbraio 2014, Krzysztof Sobkowiak <
> krzys.sobkowiak@gmail.com>
> ha scritto:
>
> > I think, the enterprise features extracted form Karaf should be still
> part
> > of Karaf project (as a sub-project) as the features should be in
> particular
> > Karaf extensions which can be easily installed on vanilla Karaf. I think
> > they are more related to Karaf than related to ServiceMix. ServiceMix
> will
> > be only a custom Karaf distribution assembling the features needed for
> ESB.
> > I don't think the ServiceMix distribution will include the EJB features -
> > it will be rather installed on vanilla Karaf (adding the EJB
> > functionality) or shipped as a custom distribution (KarafEE) than
> shipped
> > with ServiceMix. I think, all enterprise features should be maintained
> by
> > a Karaf subproject, which should also contain the current ServiceMix
> > features, like Activiti.
> >
> > Best regards
> > Krzysztof
> >
> > On 11.02.2014 12:34, Achim Nierbeck wrote:
> >
> >> Hi,
> >>
> >> sounds reasonable to me, we might be able to push those enterprise
> >> features
> >> of Karaf to ServiceMix.
> >> So have "Released" Feature descriptors available from ServiceMix and a
> >> pre-assembled ServiceMix Container with dedicated features.
> >> This way it's easier to have those openEJB features and other stuff that
> >> runs on top of Karaf at one place.
> >> For example the right now kind of "neglected" WebConsole of Karaf could
> be
> >> moved here.
> >> This way we'd have a one Console fit's them all, but again on feature
> >> basis, so everyone is either free to install
> >> and use it or use something different :)
> >>
> >> regards, Achim
> >>
> >>
> >> 2014-02-11 11:55 GMT+01:00 Krzysztof Sobkowiak <
> krzys.sobkowiak@gmail.com
> >> >:
> >>
> >> Hi
> >>>
> >>> In my opinion we should have a custom Karaf distribution in Apache
> which
> >>> assemblies Camel, CXF, ActiveMQ, some BPM (e.g. Activiti). It can still
> >>> be
> >>> ServiceMix. We should only think about making ServiceMix better
> >>> upgradeable
> >>> to the new Karaf kernel. I think also, we should start ServiceMix with
> >>> Karaf 3.x.
> >>>
> >>> 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
> >
>
Re: To servicemix or not to servicemix
Posted by Gert Vanthienen <ge...@gmail.com>.
Hi Mike,
What we did there for a few other projects, is provide a
bill-of-materials POM that can be included using Maven's import scope.
It doesn't solve all the issues, but it does allow people to quickly
define managed dependencies for Camel, Karaf, CXF, ... We could fairly
easily generate such a POM file, I think.
One drawback of this approach is that it doesn't provide you with
properties that define these versions, but on the plus side, it
doesn't force users to inherit from a parent POM of ours (for which
they usually have to override things like SCM urls or Apache release
related plugins). If we use our own examples to document the
approach, that might take us a good step in the right direction.
If that sounds OK, feel free to raise a JIRA issue for this in
https://issues.apache.org/jira/browse/SM
Regards,
Gert Vanthienen
On Tue, Feb 11, 2014 at 6:20 PM, Mike K <mi...@gmail.com> wrote:
> Hello SMX team,
>
> Would you mind to think about creating parent POM that can define all
> versions for direct dependencies of Karaf, Camel, AMQ and CXF?
> Currently each project has own "parent" and current SMX uses NMR external
> POM that makes very difficult component version upgrades.
> No, I don't know how to do it right to have in parallel SMX parent and each
> top component parent, where component parent will not be used for
> dependencies version definition.
> For example, something will parse each (Karaf, Camel, CXF, AMQ) parent POMs
> and append appropriate info to new SMX parent POM, resulting POM will have
> all versions in single place, yes it will rebuild all top components to get
> SMX.
>
> Right now versions are hardcoded at component parent POM, for example Camel
> <jackson-version>1.9.12</jackson-version>
> <jackson2-version>2.2.2</jackson2-version>
> <jackrabbit-version>2.2.12</jackrabbit-version>
> <jain-sip-ri-bundle-version>1.2.154_2</jain-sip-ri-bundle-version>
> <jasper-bundle-version>6.0.36_1</jasper-bundle-version>
> <jasypt-bundle-version>1.9.1_1</jasypt-bundle-version>
> <jasypt-version>1.9.1</jasypt-version>
>
> If I need to use in resulting SMX Jackson 1.9.13 than it breaks Camel routes
> due to version mismatch and so on.
>
> PaxLogging even more complicated.
>
> Mike.
>
>
> -----Original Message----- From: Cristiano Costantini
> Sent: Tuesday, February 11, 2014 8:56 AM
>
> To: users@servicemix.apache.org
> Subject: Re: To servicemix or not to servicemix
>
> I fully agree with the strategy proposed by Krzysztof ;-)
>
> Il martedě 11 febbraio 2014, Krzysztof Sobkowiak <kr...@gmail.com>
>
> ha scritto:
>
>> I think, the enterprise features extracted form Karaf should be still part
>> of Karaf project (as a sub-project) as the features should be in
>> particular
>> Karaf extensions which can be easily installed on vanilla Karaf. I think
>> they are more related to Karaf than related to ServiceMix. ServiceMix will
>> be only a custom Karaf distribution assembling the features needed for
>> ESB.
>> I don't think the ServiceMix distribution will include the EJB features -
>> it will be rather installed on vanilla Karaf (adding the EJB
>> functionality) or shipped as a custom distribution (KarafEE) than
>> shipped
>> with ServiceMix. I think, all enterprise features should be maintained by
>> a Karaf subproject, which should also contain the current ServiceMix
>> features, like Activiti.
>>
>> Best regards
>> Krzysztof
>>
>> On 11.02.2014 12:34, Achim Nierbeck wrote:
>>
>>> Hi,
>>>
>>> sounds reasonable to me, we might be able to push those enterprise
>>> features
>>> of Karaf to ServiceMix.
>>> So have "Released" Feature descriptors available from ServiceMix and a
>>> pre-assembled ServiceMix Container with dedicated features.
>>> This way it's easier to have those openEJB features and other stuff that
>>> runs on top of Karaf at one place.
>>> For example the right now kind of "neglected" WebConsole of Karaf could
>>> be
>>> moved here.
>>> This way we'd have a one Console fit's them all, but again on feature
>>> basis, so everyone is either free to install
>>> and use it or use something different :)
>>>
>>> regards, Achim
>>>
>>>
>>> 2014-02-11 11:55 GMT+01:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com
>>> >:
>>>
>>> Hi
>>>>
>>>>
>>>> In my opinion we should have a custom Karaf distribution in Apache which
>>>> assemblies Camel, CXF, ActiveMQ, some BPM (e.g. Activiti). It can still
>>>> be
>>>> ServiceMix. We should only think about making ServiceMix better
>>>> upgradeable
>>>> to the new Karaf kernel. I think also, we should start ServiceMix with
>>>> Karaf 3.x.
>>>>
>>>> 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
>>
>
>
> ---
> 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 Cristiano Costantini <cr...@gmail.com>.
Hi Mike, hi all,
Hi think this specific topic and other like this should be addressed in a
different post to reduce entropy,
I find quite hard to read the mail on this subject mixing high level
opinions on the future of ServiceMix with specific proposal of what to do
;-)
2014-02-11 18:20 GMT+01:00 Mike K <mi...@gmail.com>:
> Hello SMX team,
>
> Would you mind to think about creating parent POM that can define all
> versions for direct dependencies of Karaf, Camel, AMQ and CXF?
> Currently each project has own "parent" and current SMX uses NMR external
> POM that makes very difficult component version upgrades.
> No, I don't know how to do it right to have in parallel SMX parent and
> each top component parent, where component parent will not be used for
> dependencies version definition.
> For example, something will parse each (Karaf, Camel, CXF, AMQ) parent
> POMs and append appropriate info to new SMX parent POM, resulting POM will
> have all versions in single place, yes it will rebuild all top components
> to get SMX.
>
> Right now versions are hardcoded at component parent POM, for example Camel
> <jackson-version>1.9.12</jackson-version>
> <jackson2-version>2.2.2</jackson2-version>
> <jackrabbit-version>2.2.12</jackrabbit-version>
> <jain-sip-ri-bundle-version>1.2.154_2</jain-sip-ri-bundle-version>
> <jasper-bundle-version>6.0.36_1</jasper-bundle-version>
> <jasypt-bundle-version>1.9.1_1</jasypt-bundle-version>
> <jasypt-version>1.9.1</jasypt-version>
>
> If I need to use in resulting SMX Jackson 1.9.13 than it breaks Camel
> routes due to version mismatch and so on.
>
> PaxLogging even more complicated.
>
> Mike.
>
>
> -----Original Message----- From: Cristiano Costantini
> Sent: Tuesday, February 11, 2014 8:56 AM
>
> To: users@servicemix.apache.org
> Subject: Re: To servicemix or not to servicemix
>
> I fully agree with the strategy proposed by Krzysztof ;-)
>
> Il martedě 11 febbraio 2014, Krzysztof Sobkowiak <
> krzys.sobkowiak@gmail.com>
>
> ha scritto:
>
> I think, the enterprise features extracted form Karaf should be still part
>> of Karaf project (as a sub-project) as the features should be in
>> particular
>> Karaf extensions which can be easily installed on vanilla Karaf. I think
>> they are more related to Karaf than related to ServiceMix. ServiceMix will
>> be only a custom Karaf distribution assembling the features needed for
>> ESB.
>> I don't think the ServiceMix distribution will include the EJB features -
>> it will be rather installed on vanilla Karaf (adding the EJB
>> functionality) or shipped as a custom distribution (KarafEE) than
>> shipped
>> with ServiceMix. I think, all enterprise features should be maintained by
>> a Karaf subproject, which should also contain the current ServiceMix
>> features, like Activiti.
>>
>> Best regards
>> Krzysztof
>>
>> On 11.02.2014 12:34, Achim Nierbeck wrote:
>>
>> Hi,
>>>
>>> sounds reasonable to me, we might be able to push those enterprise
>>> features
>>> of Karaf to ServiceMix.
>>> So have "Released" Feature descriptors available from ServiceMix and a
>>> pre-assembled ServiceMix Container with dedicated features.
>>> This way it's easier to have those openEJB features and other stuff that
>>> runs on top of Karaf at one place.
>>> For example the right now kind of "neglected" WebConsole of Karaf could
>>> be
>>> moved here.
>>> This way we'd have a one Console fit's them all, but again on feature
>>> basis, so everyone is either free to install
>>> and use it or use something different :)
>>>
>>> regards, Achim
>>>
>>>
>>> 2014-02-11 11:55 GMT+01:00 Krzysztof Sobkowiak <
>>> krzys.sobkowiak@gmail.com
>>> >:
>>>
>>> Hi
>>>
>>>>
>>>> In my opinion we should have a custom Karaf distribution in Apache which
>>>> assemblies Camel, CXF, ActiveMQ, some BPM (e.g. Activiti). It can still
>>>> be
>>>> ServiceMix. We should only think about making ServiceMix better
>>>> upgradeable
>>>> to the new Karaf kernel. I think also, we should start ServiceMix with
>>>> Karaf 3.x.
>>>>
>>>> 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
>>
>>
>
> ---
> 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 Mike K <mi...@gmail.com>.
Hello SMX team,
Would you mind to think about creating parent POM that can define all
versions for direct dependencies of Karaf, Camel, AMQ and CXF?
Currently each project has own "parent" and current SMX uses NMR external
POM that makes very difficult component version upgrades.
No, I don't know how to do it right to have in parallel SMX parent and each
top component parent, where component parent will not be used for
dependencies version definition.
For example, something will parse each (Karaf, Camel, CXF, AMQ) parent POMs
and append appropriate info to new SMX parent POM, resulting POM will have
all versions in single place, yes it will rebuild all top components to get
SMX.
Right now versions are hardcoded at component parent POM, for example Camel
<jackson-version>1.9.12</jackson-version>
<jackson2-version>2.2.2</jackson2-version>
<jackrabbit-version>2.2.12</jackrabbit-version>
<jain-sip-ri-bundle-version>1.2.154_2</jain-sip-ri-bundle-version>
<jasper-bundle-version>6.0.36_1</jasper-bundle-version>
<jasypt-bundle-version>1.9.1_1</jasypt-bundle-version>
<jasypt-version>1.9.1</jasypt-version>
If I need to use in resulting SMX Jackson 1.9.13 than it breaks Camel routes
due to version mismatch and so on.
PaxLogging even more complicated.
Mike.
-----Original Message-----
From: Cristiano Costantini
Sent: Tuesday, February 11, 2014 8:56 AM
To: users@servicemix.apache.org
Subject: Re: To servicemix or not to servicemix
I fully agree with the strategy proposed by Krzysztof ;-)
Il martedì 11 febbraio 2014, Krzysztof Sobkowiak <kr...@gmail.com>
ha scritto:
> I think, the enterprise features extracted form Karaf should be still part
> of Karaf project (as a sub-project) as the features should be in
> particular
> Karaf extensions which can be easily installed on vanilla Karaf. I think
> they are more related to Karaf than related to ServiceMix. ServiceMix will
> be only a custom Karaf distribution assembling the features needed for
> ESB.
> I don't think the ServiceMix distribution will include the EJB features -
> it will be rather installed on vanilla Karaf (adding the EJB
> functionality) or shipped as a custom distribution (KarafEE) than
> shipped
> with ServiceMix. I think, all enterprise features should be maintained by
> a Karaf subproject, which should also contain the current ServiceMix
> features, like Activiti.
>
> Best regards
> Krzysztof
>
> On 11.02.2014 12:34, Achim Nierbeck wrote:
>
>> Hi,
>>
>> sounds reasonable to me, we might be able to push those enterprise
>> features
>> of Karaf to ServiceMix.
>> So have "Released" Feature descriptors available from ServiceMix and a
>> pre-assembled ServiceMix Container with dedicated features.
>> This way it's easier to have those openEJB features and other stuff that
>> runs on top of Karaf at one place.
>> For example the right now kind of "neglected" WebConsole of Karaf could
>> be
>> moved here.
>> This way we'd have a one Console fit's them all, but again on feature
>> basis, so everyone is either free to install
>> and use it or use something different :)
>>
>> regards, Achim
>>
>>
>> 2014-02-11 11:55 GMT+01:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com
>> >:
>>
>> Hi
>>>
>>> In my opinion we should have a custom Karaf distribution in Apache which
>>> assemblies Camel, CXF, ActiveMQ, some BPM (e.g. Activiti). It can still
>>> be
>>> ServiceMix. We should only think about making ServiceMix better
>>> upgradeable
>>> to the new Karaf kernel. I think also, we should start ServiceMix with
>>> Karaf 3.x.
>>>
>>> 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
>
---
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 Cristiano Costantini <cr...@gmail.com>.
I fully agree with the strategy proposed by Krzysztof ;-)
Il martedì 11 febbraio 2014, Krzysztof Sobkowiak <kr...@gmail.com>
ha scritto:
> I think, the enterprise features extracted form Karaf should be still part
> of Karaf project (as a sub-project) as the features should be in particular
> Karaf extensions which can be easily installed on vanilla Karaf. I think
> they are more related to Karaf than related to ServiceMix. ServiceMix will
> be only a custom Karaf distribution assembling the features needed for ESB.
> I don't think the ServiceMix distribution will include the EJB features -
> it will be rather installed on vanilla Karaf (adding the EJB
> functionality) or shipped as a custom distribution (KarafEE) than shipped
> with ServiceMix. I think, all enterprise features should be maintained by
> a Karaf subproject, which should also contain the current ServiceMix
> features, like Activiti.
>
> Best regards
> Krzysztof
>
> On 11.02.2014 12:34, Achim Nierbeck wrote:
>
>> Hi,
>>
>> sounds reasonable to me, we might be able to push those enterprise
>> features
>> of Karaf to ServiceMix.
>> So have "Released" Feature descriptors available from ServiceMix and a
>> pre-assembled ServiceMix Container with dedicated features.
>> This way it's easier to have those openEJB features and other stuff that
>> runs on top of Karaf at one place.
>> For example the right now kind of "neglected" WebConsole of Karaf could be
>> moved here.
>> This way we'd have a one Console fit's them all, but again on feature
>> basis, so everyone is either free to install
>> and use it or use something different :)
>>
>> regards, Achim
>>
>>
>> 2014-02-11 11:55 GMT+01:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com
>> >:
>>
>> Hi
>>>
>>> In my opinion we should have a custom Karaf distribution in Apache which
>>> assemblies Camel, CXF, ActiveMQ, some BPM (e.g. Activiti). It can still
>>> be
>>> ServiceMix. We should only think about making ServiceMix better
>>> upgradeable
>>> to the new Karaf kernel. I think also, we should start ServiceMix with
>>> Karaf 3.x.
>>>
>>> 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
>
Re: To servicemix or not to servicemix
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
I think, the enterprise features extracted form Karaf should be still
part of Karaf project (as a sub-project) as the features should be in
particular Karaf extensions which can be easily installed on vanilla
Karaf. I think they are more related to Karaf than related to
ServiceMix. ServiceMix will be only a custom Karaf distribution
assembling the features needed for ESB. I don't think the ServiceMix
distribution will include the EJB features - it will be rather
installed on vanilla Karaf (adding the EJB functionality) or shipped
as a custom distribution (KarafEE) than shipped with ServiceMix. I
think, all enterprise features should be maintained by a Karaf
subproject, which should also contain the current ServiceMix features,
like Activiti.
Best regards
Krzysztof
On 11.02.2014 12:34, Achim Nierbeck wrote:
> Hi,
>
> sounds reasonable to me, we might be able to push those enterprise features
> of Karaf to ServiceMix.
> So have "Released" Feature descriptors available from ServiceMix and a
> pre-assembled ServiceMix Container with dedicated features.
> This way it's easier to have those openEJB features and other stuff that
> runs on top of Karaf at one place.
> For example the right now kind of "neglected" WebConsole of Karaf could be
> moved here.
> This way we'd have a one Console fit's them all, but again on feature
> basis, so everyone is either free to install
> and use it or use something different :)
>
> regards, Achim
>
>
> 2014-02-11 11:55 GMT+01:00 Krzysztof Sobkowiak <kr...@gmail.com>:
>
>> Hi
>>
>> In my opinion we should have a custom Karaf distribution in Apache which
>> assemblies Camel, CXF, ActiveMQ, some BPM (e.g. Activiti). It can still be
>> ServiceMix. We should only think about making ServiceMix better upgradeable
>> to the new Karaf kernel. I think also, we should start ServiceMix with
>> Karaf 3.x.
>>
>> 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
Re: To servicemix or not to servicemix
Posted by ggerla <gi...@gmail.com>.
Hi Cristiano, hi all
I wanted to thank you for this discussion because I realized the true path
of servicemix and Karaf.
Two words on my personal experience. After starting to use Servicemix, I
switched to Karaf because I used only the OSGi core. Recently I came-back to
Servicemix for convenience since I started using spring-orm and ActiveMQ.
My goal, however, is to use Karaf or with a custom distribution or with a
feature since in this way I have more flexibility on the libraries version.
In conclusion, I agree with the proposed strategy, and I'm available to help
with developments.
Br
Giuseppe
--
View this message in context: http://servicemix.396122.n5.nabble.com/To-servicemix-or-not-to-servicemix-tp5718935p5719016.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: To servicemix or not to servicemix
Posted by Cristiano Costantini <cr...@gmail.com>.
I don't want to add more noise with a simple reply that says I agree but
this time I think it is worth:
I agree with this approach proposed by Gert :-) also I think that
discussion on "how to act" should move to dev@ mailing list.
Then, I was curiously trying to rebuild the history of Karaf. Before I
had an overall idea but not certainty.
And well, I think we all shall give more focus to the fact that Karaf comes
from the ServiceMix Kernel:
http://web.archive.org/web/20120102122544/http://servicemix.apache.org/kernel
This is not just something about pride, it is more about credibility of the
solution of Karaf. Remember when I say that ServiceMix has a "(debatable)
marketing value"? Well, if we outline Karaf comes from ServiceMix's Kernel,
this value get transferred to Karaf too.
Also, it is a Shame that nowhere on the home page of Karaf is a quote to
its origin.
Saying that "most of the work that used to be at SerivceMix is now
happening at Karaf and Camel instead" can be discouraging if we don't have
clear view of the history. Claus surely has this clear view, but me and
many other developers may not, and I can misunderstand what he means.
This nice link summarize the history of Karaf:
http://icodebythesea.blogspot.it/2011/01/brief-history-of-apache-karaf.html
Regards,
Cristiano
> Personally, I'd think the best place to start would be with the
> ServiceMix 5 codebase - that already removes the NMR/JBI bits, so we
> have a good starting point there. I'd be inclined to remove the extra
> Camel stuff we have there at the moment and focus on the core
> assembly, the examples and the new pax-exam-karaf based integration
> tests first. That way, it's easy for people to get involved and we
> have a nice attainable goal in getting a first non-JBI/NMR assembly
> out without the burden of any extra code.
>
> Once we agree on the approach, I would try to get some of the tasks
> registered in JIRA so people interested in contributing have some
> place to go and look for things they can help out with.
>
> I'd also like to invite everyone who expressed an interest in
> contributing to join the dev@ mailing list as well (cfr.
> http://servicemix.apache.org/community/mailing-lists.html for more
> info). As we start working on this, that's where you can get in touch
> and follow up on what's happening with the JIRA issues.
>
>
> Regards,
>
> Gert
> Regards,
>
> Gert Vanthienen
>
>
> On Tue, Feb 11, 2014 at 3:22 PM, Johan Edstrom <se...@gmail.com> wrote:
> > Where do we want to start?
> > Gert and I spoke about this quite a long time ago, what really is needed
> is a new parent Pom - then removal of NMR/Jbi as direct deps, maybe those
> two could be better solved with embedded and hidden older jars.
> >
> > Sent from my pressure cooker.
> >
> >> On Feb 11, 2014, at 9:11, Krzysztof Sobkowiak <
> krzys.sobkowiak@gmail.com> wrote:
> >>
> >> I'm ready to contribute to ServiceMix (and Karaf too) but the next 4
> weeks I have still limited time capacities (due to the trainings I'm
> preparing for my company)
> >>
> >> regards
> >> Krzysztof
> >>
> >>> On 11.02.2014 14:46, Achim Nierbeck wrote:
> >>> I wonder when and why that happened ....
> >>> ... but this is a good point for all those people that
> >>> raised their voices the last 4 days to show their pride of
> >>> the project and get into it ;)
> >>>
> >>> regards, Achim
> >>
> >> --
> >> 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 Gert Vanthienen <ge...@gmail.com>.
L.S.,
Personally, I'd think the best place to start would be with the
ServiceMix 5 codebase - that already removes the NMR/JBI bits, so we
have a good starting point there. I'd be inclined to remove the extra
Camel stuff we have there at the moment and focus on the core
assembly, the examples and the new pax-exam-karaf based integration
tests first. That way, it's easy for people to get involved and we
have a nice attainable goal in getting a first non-JBI/NMR assembly
out without the burden of any extra code.
Once we agree on the approach, I would try to get some of the tasks
registered in JIRA so people interested in contributing have some
place to go and look for things they can help out with.
I'd also like to invite everyone who expressed an interest in
contributing to join the dev@ mailing list as well (cfr.
http://servicemix.apache.org/community/mailing-lists.html for more
info). As we start working on this, that's where you can get in touch
and follow up on what's happening with the JIRA issues.
Regards,
Gert
Regards,
Gert Vanthienen
On Tue, Feb 11, 2014 at 3:22 PM, Johan Edstrom <se...@gmail.com> wrote:
> Where do we want to start?
> Gert and I spoke about this quite a long time ago, what really is needed is a new parent Pom - then removal of NMR/Jbi as direct deps, maybe those two could be better solved with embedded and hidden older jars.
>
> Sent from my pressure cooker.
>
>> On Feb 11, 2014, at 9:11, Krzysztof Sobkowiak <kr...@gmail.com> wrote:
>>
>> I'm ready to contribute to ServiceMix (and Karaf too) but the next 4 weeks I have still limited time capacities (due to the trainings I'm preparing for my company)
>>
>> regards
>> Krzysztof
>>
>>> On 11.02.2014 14:46, Achim Nierbeck wrote:
>>> I wonder when and why that happened ....
>>> ... but this is a good point for all those people that
>>> raised their voices the last 4 days to show their pride of
>>> the project and get into it ;)
>>>
>>> regards, Achim
>>
>> --
>> 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 Johan Edstrom <se...@gmail.com>.
Where do we want to start?
Gert and I spoke about this quite a long time ago, what really is needed is a new parent Pom - then removal of NMR/Jbi as direct deps, maybe those two could be better solved with embedded and hidden older jars.
Sent from my pressure cooker.
> On Feb 11, 2014, at 9:11, Krzysztof Sobkowiak <kr...@gmail.com> wrote:
>
> I'm ready to contribute to ServiceMix (and Karaf too) but the next 4 weeks I have still limited time capacities (due to the trainings I'm preparing for my company)
>
> regards
> Krzysztof
>
>> On 11.02.2014 14:46, Achim Nierbeck wrote:
>> I wonder when and why that happened ....
>> ... but this is a good point for all those people that
>> raised their voices the last 4 days to show their pride of
>> the project and get into it ;)
>>
>> regards, Achim
>
> --
> 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 Krzysztof Sobkowiak <kr...@gmail.com>.
I'm ready to contribute to ServiceMix (and Karaf too) but the next 4
weeks I have still limited time capacities (due to the trainings I'm
preparing for my company)
regards
Krzysztof
On 11.02.2014 14:46, Achim Nierbeck wrote:
> I wonder when and why that happened ....
> ... but this is a good point for all those people that
> raised their voices the last 4 days to show their pride of
> the project and get into it ;)
>
> regards, Achim
>
>
--
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 Achim Nierbeck <bc...@googlemail.com>.
I wonder when and why that happened ....
... but this is a good point for all those people that
raised their voices the last 4 days to show their pride of
the project and get into it ;)
regards, Achim
2014-02-11 13:37 GMT+01:00 Ioannis Canellos <io...@gmail.com>:
> Users would definitely want to have an aggregate project. The question
> is if there are enough contributors to maintain it.
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel
>
--
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/>
Re: To servicemix or not to servicemix
Posted by Ioannis Canellos <io...@gmail.com>.
Users would definitely want to have an aggregate project. The question
is if there are enough contributors to maintain it.
--
Ioannis Canellos
Blog: http://iocanel.blogspot.com
Twitter: iocanel
Re: To servicemix or not to servicemix
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
sounds reasonable to me, we might be able to push those enterprise features
of Karaf to ServiceMix.
So have "Released" Feature descriptors available from ServiceMix and a
pre-assembled ServiceMix Container with dedicated features.
This way it's easier to have those openEJB features and other stuff that
runs on top of Karaf at one place.
For example the right now kind of "neglected" WebConsole of Karaf could be
moved here.
This way we'd have a one Console fit's them all, but again on feature
basis, so everyone is either free to install
and use it or use something different :)
regards, Achim
2014-02-11 11:55 GMT+01:00 Krzysztof Sobkowiak <kr...@gmail.com>:
> Hi
>
> In my opinion we should have a custom Karaf distribution in Apache which
> assemblies Camel, CXF, ActiveMQ, some BPM (e.g. Activiti). It can still be
> ServiceMix. We should only think about making ServiceMix better upgradeable
> to the new Karaf kernel. I think also, we should start ServiceMix with
> Karaf 3.x.
>
> Best regards
> Krzysztof
>
>
>
> On 11.02.2014 08:46, Achim Nierbeck wrote:
>
>> It's good to see so much support for ServiceMix again.
>> Looks like a valuable Community is forming up again.
>> GREAT :)
>>
>> The reason I told Cristiano to stick to a "self" made
>> "servicmix-like-container"
>> is just the turn around timings we do have right now.
>> And this is just due to the fact that most of the work is done by just to
>> few people.
>> Correct me if I'm wrong but right now we have about two people for
>> Servicmix and
>> one for Karaf doing 80+ % of the work, at least this is my impression.
>>
>> So anyone interested in keeping Servicemix alive (including me ;) ) should
>> go ahead and
>> try to fix stuff that seems wrong (in documentation or src) help keeping
>> those turn around timings on releasing low :D
>>
>> regards, Achim
>>
>>
>> 2014-02-11 8:41 GMT+01:00 Bart Horré <ba...@anova.be>:
>>
>> Hi all,
>>>
>>> I'm also "interested in having an Apache
>>> project that is solely about combining ActiveMQ, Camel, CXF, Karaf and a
>>> few other things into a single integration platform distribution"
>>>
>>> Like in Andrew's case, ServiceMix was my start in the road to getting to
>>> know Camel, ActiveMQ, CXF, Karaf, ...
>>> I didn't really realize at the time a started out, but I am glad there is
>>> an out of the box solution which supports all these technologies without
>>> a
>>> hassle.
>>>
>>> Regards
>>>
>>> Bart Horré
>>>
>>>
>>>
>>> On Tue, Feb 11, 2014 at 5:45 AM, Cristiano Costantini <
>>> cristiano.costantini@gmail.com> wrote:
>>>
>>> Il lunedì 10 febbraio 2014, Andrew Thorburn <nz...@gmail.com> ha
>>>>
>>> scritto:
>>>
>>>> The one other thing I would like to add is that I do use the NMR,
>>>>>
>>>> simply
>>>
>>>> as
>>>>
>>>>> a really easy way to connect two Camel routes in separate bundles
>>>>>
>>>> without
>>>
>>>> the hassle of trying to configure JMS routes
>>>>>
>>>>> Hi Andrew,
>>>> I used NMR too but now I use the Camel VM component for the same
>>>> purpose.
>>>>
>>>> Regards
>>>>
>>>>
>>
>>
>
> --
> 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
>
--
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/>
Re: To servicemix or not to servicemix
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hi
In my opinion we should have a custom Karaf distribution in Apache which
assemblies Camel, CXF, ActiveMQ, some BPM (e.g. Activiti). It can still
be ServiceMix. We should only think about making ServiceMix better
upgradeable to the new Karaf kernel. I think also, we should start
ServiceMix with Karaf 3.x.
Best regards
Krzysztof
On 11.02.2014 08:46, Achim Nierbeck wrote:
> It's good to see so much support for ServiceMix again.
> Looks like a valuable Community is forming up again.
> GREAT :)
>
> The reason I told Cristiano to stick to a "self" made
> "servicmix-like-container"
> is just the turn around timings we do have right now.
> And this is just due to the fact that most of the work is done by just to
> few people.
> Correct me if I'm wrong but right now we have about two people for
> Servicmix and
> one for Karaf doing 80+ % of the work, at least this is my impression.
>
> So anyone interested in keeping Servicemix alive (including me ;) ) should
> go ahead and
> try to fix stuff that seems wrong (in documentation or src) help keeping
> those turn around timings on releasing low :D
>
> regards, Achim
>
>
> 2014-02-11 8:41 GMT+01:00 Bart Horré <ba...@anova.be>:
>
>> Hi all,
>>
>> I'm also "interested in having an Apache
>> project that is solely about combining ActiveMQ, Camel, CXF, Karaf and a
>> few other things into a single integration platform distribution"
>>
>> Like in Andrew's case, ServiceMix was my start in the road to getting to
>> know Camel, ActiveMQ, CXF, Karaf, ...
>> I didn't really realize at the time a started out, but I am glad there is
>> an out of the box solution which supports all these technologies without a
>> hassle.
>>
>> Regards
>>
>> Bart Horré
>>
>>
>>
>> On Tue, Feb 11, 2014 at 5:45 AM, Cristiano Costantini <
>> cristiano.costantini@gmail.com> wrote:
>>
>>> Il lunedì 10 febbraio 2014, Andrew Thorburn <nz...@gmail.com> ha
>> scritto:
>>>> The one other thing I would like to add is that I do use the NMR,
>> simply
>>> as
>>>> a really easy way to connect two Camel routes in separate bundles
>> without
>>>> the hassle of trying to configure JMS routes
>>>>
>>> Hi Andrew,
>>> I used NMR too but now I use the Camel VM component for the same purpose.
>>>
>>> Regards
>>>
>
>
--
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 Achim Nierbeck <bc...@googlemail.com>.
It's good to see so much support for ServiceMix again.
Looks like a valuable Community is forming up again.
GREAT :)
The reason I told Cristiano to stick to a "self" made
"servicmix-like-container"
is just the turn around timings we do have right now.
And this is just due to the fact that most of the work is done by just to
few people.
Correct me if I'm wrong but right now we have about two people for
Servicmix and
one for Karaf doing 80+ % of the work, at least this is my impression.
So anyone interested in keeping Servicemix alive (including me ;) ) should
go ahead and
try to fix stuff that seems wrong (in documentation or src) help keeping
those turn around timings on releasing low :D
regards, Achim
2014-02-11 8:41 GMT+01:00 Bart Horré <ba...@anova.be>:
> Hi all,
>
> I'm also "interested in having an Apache
> project that is solely about combining ActiveMQ, Camel, CXF, Karaf and a
> few other things into a single integration platform distribution"
>
> Like in Andrew's case, ServiceMix was my start in the road to getting to
> know Camel, ActiveMQ, CXF, Karaf, ...
> I didn't really realize at the time a started out, but I am glad there is
> an out of the box solution which supports all these technologies without a
> hassle.
>
> Regards
>
> Bart Horré
>
>
>
> On Tue, Feb 11, 2014 at 5:45 AM, Cristiano Costantini <
> cristiano.costantini@gmail.com> wrote:
>
> > Il lunedì 10 febbraio 2014, Andrew Thorburn <nz...@gmail.com> ha
> scritto:
> >
> > >
> > > The one other thing I would like to add is that I do use the NMR,
> simply
> > as
> > > a really easy way to connect two Camel routes in separate bundles
> without
> > > the hassle of trying to configure JMS routes
> > >
> >
> > Hi Andrew,
> > I used NMR too but now I use the Camel VM component for the same purpose.
> >
> > Regards
> >
>
--
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/>
Re: To servicemix or not to servicemix
Posted by Bart Horré <ba...@anova.be>.
Hi all,
I'm also "interested in having an Apache
project that is solely about combining ActiveMQ, Camel, CXF, Karaf and a
few other things into a single integration platform distribution"
Like in Andrew's case, ServiceMix was my start in the road to getting to
know Camel, ActiveMQ, CXF, Karaf, ...
I didn't really realize at the time a started out, but I am glad there is
an out of the box solution which supports all these technologies without a
hassle.
Regards
Bart Horré
On Tue, Feb 11, 2014 at 5:45 AM, Cristiano Costantini <
cristiano.costantini@gmail.com> wrote:
> Il lunedì 10 febbraio 2014, Andrew Thorburn <nz...@gmail.com> ha scritto:
>
> >
> > The one other thing I would like to add is that I do use the NMR, simply
> as
> > a really easy way to connect two Camel routes in separate bundles without
> > the hassle of trying to configure JMS routes
> >
>
> Hi Andrew,
> I used NMR too but now I use the Camel VM component for the same purpose.
>
> Regards
>
Re: To servicemix or not to servicemix
Posted by Cristiano Costantini <cr...@gmail.com>.
Il lunedì 10 febbraio 2014, Andrew Thorburn <nz...@gmail.com> ha scritto:
>
> The one other thing I would like to add is that I do use the NMR, simply as
> a really easy way to connect two Camel routes in separate bundles without
> the hassle of trying to configure JMS routes
>
Hi Andrew,
I used NMR too but now I use the Camel VM component for the same purpose.
Regards
Re: To servicemix or not to servicemix
Posted by Andrew Thorburn <nz...@gmail.com>.
Hey guys,
I'd like to add my support for SMX sticking around as its own thing - we've
recently started using SMX where I work, and it saved me an awful lot of
time, along with leading me to things like Apache Karaf - which I had not
heard of before I started using SMX.
Personally, the most valuable thing that SMX provided me was a collection
of features that are known to play well together, which meant that I could
spend most of my time learning how to *use* those features, rather than
trying to assemble them all together and *then* learning how to use them -
which could be a pretty significant amount of time.
The one other thing I would like to add is that I do use the NMR, simply as
a really easy way to connect two Camel routes in separate bundles without
the hassle of trying to configure JMS routes (this also means that I can
undeploy bundle X, while leaving bundles Y and Z in-place, which is
important for me). I'm sure I could find something to replace it, but
that's the easiest solution for me right now.
I don't know if I could do much to help, except to say that, yes, SMX was
absolutely useful to me, and I would like to see it stick around.
Thanks,
- Andrew
On Tue, Feb 11, 2014 at 11:18 AM, Christian Müller <
christian.mueller@gmail.com> wrote:
> Hi Gert, hi all!
>
> I think there is really a need for an open source ESB. In my opinion, it
> should be Apache ServiceMix X.
>
> If it helps, drop the (legacy) support for ServiceMix 4.x and restart with
> ServiceMix 5 which should be more easily to maintain.
>
> Ping me, if you have something specific I can work on. You can count on me!
>
> Best,
> Christian
> -----------------
>
> Software Integration Specialist
>
> Apache Member
> V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
> Apache Incubator PMC Member
>
> https://www.linkedin.com/pub/christian-mueller/11/551/642
>
>
> On Mon, Feb 10, 2014 at 2:16 PM, Gert Vanthienen
> <ge...@gmail.com>wrote:
>
> > L.S.,
> >
> >
> > First of all, thank you for starting this discussion! I definitely
> > agree with everything that has already been said on this thread. We
> > have been ignoring the important, key question for far too long on our
> > mailing lists: Is there a community of users that are interested in
> > having an Apache project that is solely about combining ActiveMQ,
> > Camel, CXF, Karaf and a few other things into a single integration
> > platform distribution? That is the real question we have to answer
> > here.
> >
> > I started updating ServiceMix 4.x to the latest version a while ago,
> > but given the large legacy codebase and the number of subprojects that
> > we have, that is quite an undertaking. Apart from the JBI itests
> > issue, we would also have to get the Features project upgrade done and
> > then do all the release. This is why we restarted the ServiceMix 5
> > effort a year ago: to have a single project with just the dependency
> > versions to update and then cut a release would be a really great
> > thing, compared to the amount of work we now have to do.
> >
> > It looks like nobody out here is interested in doing all that work on
> > the 4.x line and from what I read, the jury is still out on what
> > should happen with the ServiceMix 5 effort. There probably is some
> > value in this type of distribution to get people started with the
> > entire stack of projects more easily, without having to resort to
> > vendor-specific solutions like JBoss Fuse, Fabric8, Talend ESB, ...
> > from day one.
> >
> > We really need some people to do the work though. If nobody is
> > able/willing to put in the effort, it might be better to look into
> > finishing up the project with a bit of style instead of letting it
> > slowly die in the background. With a nice announcement, pointing to
> > the appropriate documentation on the Camel, CXF, Karaf, ... websites,
> > we can definitely get the few people that end up on the ServiceMix
> > project website oriented pretty quickly towards a DIY solution
> > starting with a plain Karaf installation.
> >
> > Personally, I'm fine with either solution. I have always personally
> > liked the Apache ServiceMix project, so if there's some interest to
> > keep doing this, I'll gladly help out there. But on the other hand:
> > it's pretty hard to build a community around only a single assembly
> > project, so if there's no real interest, I'll gladly work with
> > everyone else to draft up a nice announcement and point people towards
> > a better solution as well.
> >
> > Not sure what the best way is to decide this. Perhaps start a vote on
> > what to do next? Given the meaning assigned to the different vote
> > options on https://www.apache.org/foundation/voting.html, that might
> > give us a good idea about who is actually willing/able to help out,
> > but I'm open to any suggestions here.
> >
> >
> > Regards and thanks again for getting this discussion in the open,
> >
> > Gert Vanthienen
> >
> >
> > Regards,
> >
> > Gert Vanthienen
> >
> >
> > 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
> >
>
Re: To servicemix or not to servicemix
Posted by Christian Müller <ch...@gmail.com>.
Hi Gert, hi all!
I think there is really a need for an open source ESB. In my opinion, it
should be Apache ServiceMix X.
If it helps, drop the (legacy) support for ServiceMix 4.x and restart with
ServiceMix 5 which should be more easily to maintain.
Ping me, if you have something specific I can work on. You can count on me!
Best,
Christian
-----------------
Software Integration Specialist
Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Mon, Feb 10, 2014 at 2:16 PM, Gert Vanthienen
<ge...@gmail.com>wrote:
> L.S.,
>
>
> First of all, thank you for starting this discussion! I definitely
> agree with everything that has already been said on this thread. We
> have been ignoring the important, key question for far too long on our
> mailing lists: Is there a community of users that are interested in
> having an Apache project that is solely about combining ActiveMQ,
> Camel, CXF, Karaf and a few other things into a single integration
> platform distribution? That is the real question we have to answer
> here.
>
> I started updating ServiceMix 4.x to the latest version a while ago,
> but given the large legacy codebase and the number of subprojects that
> we have, that is quite an undertaking. Apart from the JBI itests
> issue, we would also have to get the Features project upgrade done and
> then do all the release. This is why we restarted the ServiceMix 5
> effort a year ago: to have a single project with just the dependency
> versions to update and then cut a release would be a really great
> thing, compared to the amount of work we now have to do.
>
> It looks like nobody out here is interested in doing all that work on
> the 4.x line and from what I read, the jury is still out on what
> should happen with the ServiceMix 5 effort. There probably is some
> value in this type of distribution to get people started with the
> entire stack of projects more easily, without having to resort to
> vendor-specific solutions like JBoss Fuse, Fabric8, Talend ESB, ...
> from day one.
>
> We really need some people to do the work though. If nobody is
> able/willing to put in the effort, it might be better to look into
> finishing up the project with a bit of style instead of letting it
> slowly die in the background. With a nice announcement, pointing to
> the appropriate documentation on the Camel, CXF, Karaf, ... websites,
> we can definitely get the few people that end up on the ServiceMix
> project website oriented pretty quickly towards a DIY solution
> starting with a plain Karaf installation.
>
> Personally, I'm fine with either solution. I have always personally
> liked the Apache ServiceMix project, so if there's some interest to
> keep doing this, I'll gladly help out there. But on the other hand:
> it's pretty hard to build a community around only a single assembly
> project, so if there's no real interest, I'll gladly work with
> everyone else to draft up a nice announcement and point people towards
> a better solution as well.
>
> Not sure what the best way is to decide this. Perhaps start a vote on
> what to do next? Given the meaning assigned to the different vote
> options on https://www.apache.org/foundation/voting.html, that might
> give us a good idea about who is actually willing/able to help out,
> but I'm open to any suggestions here.
>
>
> Regards and thanks again for getting this discussion in the open,
>
> Gert Vanthienen
>
>
> Regards,
>
> Gert Vanthienen
>
>
> 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
>
Re: To servicemix or not to servicemix
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
First of all, thank you for starting this discussion! I definitely
agree with everything that has already been said on this thread. We
have been ignoring the important, key question for far too long on our
mailing lists: Is there a community of users that are interested in
having an Apache project that is solely about combining ActiveMQ,
Camel, CXF, Karaf and a few other things into a single integration
platform distribution? That is the real question we have to answer
here.
I started updating ServiceMix 4.x to the latest version a while ago,
but given the large legacy codebase and the number of subprojects that
we have, that is quite an undertaking. Apart from the JBI itests
issue, we would also have to get the Features project upgrade done and
then do all the release. This is why we restarted the ServiceMix 5
effort a year ago: to have a single project with just the dependency
versions to update and then cut a release would be a really great
thing, compared to the amount of work we now have to do.
It looks like nobody out here is interested in doing all that work on
the 4.x line and from what I read, the jury is still out on what
should happen with the ServiceMix 5 effort. There probably is some
value in this type of distribution to get people started with the
entire stack of projects more easily, without having to resort to
vendor-specific solutions like JBoss Fuse, Fabric8, Talend ESB, ...
from day one.
We really need some people to do the work though. If nobody is
able/willing to put in the effort, it might be better to look into
finishing up the project with a bit of style instead of letting it
slowly die in the background. With a nice announcement, pointing to
the appropriate documentation on the Camel, CXF, Karaf, ... websites,
we can definitely get the few people that end up on the ServiceMix
project website oriented pretty quickly towards a DIY solution
starting with a plain Karaf installation.
Personally, I'm fine with either solution. I have always personally
liked the Apache ServiceMix project, so if there's some interest to
keep doing this, I'll gladly help out there. But on the other hand:
it's pretty hard to build a community around only a single assembly
project, so if there's no real interest, I'll gladly work with
everyone else to draft up a nice announcement and point people towards
a better solution as well.
Not sure what the best way is to decide this. Perhaps start a vote on
what to do next? Given the meaning assigned to the different vote
options on https://www.apache.org/foundation/voting.html, that might
give us a good idea about who is actually willing/able to help out,
but I'm open to any suggestions here.
Regards and thanks again for getting this discussion in the open,
Gert Vanthienen
Regards,
Gert Vanthienen
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
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
Re: To servicemix or not to servicemix
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 Cristiano Costantini <cr...@gmail.com>.
@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!
Re: To servicemix or not to servicemix
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
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
>
>
--
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 Claus Ibsen <cl...@gmail.com>.
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
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
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
Re: To servicemix or not to servicemix
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
> <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
Re: To servicemix or not to servicemix
Posted by Mike K <mi...@gmail.com>.
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: users@servicemix.apache.org
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
To servicemix or not to servicemix
Posted by Cristiano Costantini <cr...@gmail.com>.
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
Re: To servicemix or not to servicemix
Posted by janne mattila <fr...@gmail.com>.
Hi,
got curious - could you elaborate a little, what you mean by "ESB has lost
it's traction"?
2014-02-08 11:27 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>
> Also ServiceMix is associated with ESB which in todays modern world
> lost its traction.
>
Re: To servicemix or not to servicemix
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Feb 8, 2014 at 9:48 AM, Cristiano Costantini
<cr...@gmail.com> 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 <cl...@gmail.com>:
>
>> 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.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: cibsen@redhat.com
>> 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: cibsen@redhat.com
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
Re: To servicemix or not to servicemix
Posted by Cristiano Costantini <cr...@gmail.com>.
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 <cl...@gmail.com>:
> 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.
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> 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
>
Re: To servicemix or not to servicemix
Posted by Claus Ibsen <cl...@gmail.com>.
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.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
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
Re: To servicemix or not to servicemix
Posted by Cristiano Costantini <cr...@gmail.com>.
Thank you very much for your feedback,
I'll really give it a try then.
Regards,
Cristiano
2014-02-07 Achim Nierbeck <bc...@googlemail.com>:
> 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 <cr...@gmail.com>:
>
> > 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/>
>
Re: To servicemix or not to servicemix
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <cr...@gmail.com>:
> 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/>