Hallo Raul
Yes, we want to achieve it be restarting ServiceMix 5 form scratch and
make it a custom Karaf assembly including Camel, CXF and ActiveMQ. The
rest components can be installed from features having a separate
lifecycle. I'd like the other components to be also easily installable
on vanilla Karaf. I think, the components you mentioned (Akka, Activiti,
ElasticSearch / Kibana, DropWizard, vert.x, etc) can be part of Karaf
Enterprise Features subproject mentioned by Jean-Baptiste, because
people may want to install the features in their enterprise applications
build on Karaf. I think, the best place for all enterprise features
will be a Karaf subproject. The subproject can have a separate
lifecycle, the features can be installed in vanilla Karaf or can be
installed in ServiceMix (e.g. using shell commands proposed by you.
Regards
Krzysztof
On 16.02.2014 19:58, Raul Kripalani wrote:
Hello guys,
One of the things I'd like to discuss is our approach to modularise the
additional capabilities that SMX5 provides on top of "the core" (Karaf +
Camel + CXF + AMQ), e.g. Activiti integration, Akka integration, JMS
logging appender, etc.
I would like to shift these elements to a separate "modules" repository, in
a manner analogous to the "bundles" repository of SMX [1]. In my opinion,
they should not be part of the default SMX5 assembly, and they should have
a separate lifecycle.
SMX has 4 big direct dependencies: Karaf, Camel, CXF and AMQ. In the
future, I would expect a new SMX release whenever one of these 4 projects
release upstream (ideally!). This is definitely something we can control,
especially because many members of the SMX community also belong to those
upstream communities.
Any other projects, e.g. Akka, Activiti, perhaps ElasticSearch / Kibana,
DropWizard, vert.x, etc. anything we may want to add as a "capability" to
SMX in the future, should have independent release cycles.
Then I would provide a Karaf shell so that users can "pull" these
capabilities straight from Maven Central:
karaf@root()> servicemix:module-list
(finds all the available modules and versions by querying Maven repos)
karaf@root()> servicemix:module-add akka 1.0.0
(adds version 1.0.0 of the Akka module)
In reality, these commands would mainly call a bunch of commands from the
"feature" shell behind the curtains. For example, the 2nd command would do
the following:
* Add a feature repo
mvn:org.apache.servicemix.modules/akka/1.0.0/xml/features
* Install a feature also called "akka" from this feature repo.
Basically, modules would have a "contract" such that they'd need to provide
a features repo each + a feature with the same name.
In a nutshell:
* Let's make SMX leaner by focusing on "the big 4" components.
* Independent lifecycles for additional modules or capabilities.
* Upstream dependency upgrades can be controlled and updated locally in a
more granular manner.
* Set of "servicemix" shell commands to add capabilities which are hosted
and versioned separately from the core.
What do you think?
Regards,
[1] https://github.com/apache/servicemix4-bundles
*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk
--
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
