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: [email protected] <mailto:[email protected]> |
Twitter: @KSobkowiak
