To servicemix or not to servicemix

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

Re: To servicemix or not to servicemix

Matt Wendling
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 <
[hidden email]> wrote:

> I fully agree with the strategy proposed by Krzysztof ;-)
>
> Il martedì 11 febbraio 2014, Krzysztof Sobkowiak <
> [hidden email]>
> 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 <
> [hidden email]
> >> >:
> >>
> >>  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: [hidden email] <mailto:[hidden email]> |
> > Twitter: @KSobkowiak
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: To servicemix or not to servicemix

ksobkowiak
In reply to this post by Jean-Baptiste Onofré
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: [hidden email] <mailto:[hidden email]> |
Twitter: @KSobkowiak
Reply | Threaded
Open this post in threaded view
|

Re: To servicemix or not to servicemix

Gert Vanthienen
Administrator
In reply to this post by Johan Edstrom-2
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email] <mailto:[hidden email]> | Twitter: @KSobkowiak
Regards,

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

Re: To servicemix or not to servicemix

Gert Vanthienen
Administrator
In reply to this post by mikek753
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 <[hidden email]> 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: [hidden email]
> Subject: Re: To servicemix or not to servicemix
>
> I fully agree with the strategy proposed by Krzysztof ;-)
>
> Il martedě 11 febbraio 2014, Krzysztof Sobkowiak <[hidden email]>
>
> 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 <[hidden email]
>>> >:
>>>
>>>  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: [hidden email] <mailto:[hidden email]> |
>> Twitter: @KSobkowiak
>>
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
Regards,

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

Re: To servicemix or not to servicemix

Cristiano Costantini
In reply to this post by mikek753
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 <[hidden email]>:

> 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: [hidden email]
> Subject: Re: To servicemix or not to servicemix
>
> I fully agree with the strategy proposed by Krzysztof ;-)
>
> Il martedě 11 febbraio 2014, Krzysztof Sobkowiak <
> [hidden email]>
>
> 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 <
>>> [hidden email]
>>> >:
>>>
>>>  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: [hidden email] <mailto:[hidden email]> |
>> Twitter: @KSobkowiak
>>
>>
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: To servicemix or not to servicemix

Cristiano Costantini
In reply to this post by Gert Vanthienen
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 <[hidden email]> 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 <
> [hidden email]> 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: [hidden email] <mailto:[hidden email]> |
> Twitter: @KSobkowiak
>
Reply | Threaded
Open this post in threaded view
|

Re: To servicemix or not to servicemix

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

Re: To servicemix or not to servicemix

Raúl Kripalani
This post was updated on .
In reply to this post by Gert Vanthienen
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 4.x 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/
Reply | Threaded
Open this post in threaded view
|

Re: To servicemix or not to servicemix

servicemix user
In reply to this post by Claus Ibsen-2
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 <[hidden email]>:

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