We don't want to add activiti to Karaf core only to Enterprise Features
subproject. I think, Activiti can be used in both, in ESB solutions or
in enterprise solutions (and should be usable outside ServiceMix, e.g.
in vanilla Karaf) and Karaf Enterprise features is very good place for it.
On 21.02.2014 19:29, Raul Kripalani wrote:
I don't understand why we'd want to burden Apache Karaf - a project focused
on providing an OSGi ecosystem - with server components that are clearly
integration-related.
BPM and OSGi have nothing to do with each other by bare nature, nor is
Activiti implementing any OSGi specification or Java EE spec.
In my opinion, building "bridges" between Karaf/OSGi and
integration-related components is the true spirit of the SMX project.
Therefore, I'd be -1 to divest this module.
Regards,
Raúl.
On Fri, Feb 21, 2014 at 6:14 PM, Krzysztof Sobkowiak <
krzys.sobkow...@gmail.com> wrote:
Hi
I'd like to have activiti feature too, as long as it can be moved into the
Karaf Features subproject. The other modules - we don't need to keep it in
core servicemix, but I think, someone has done a work to provide these
features. We can eventually keep it at least as samples for people ho want
to use such features in the future.
B.t.w., I think whether we could provide something like ServiceMix by
Example (similar to Fuse by Example). We could add there samples/demos
which we don't want to include in ServiceMix distribution.
Regards
Krzysztof
On 21.02.2014 18:02, Gert Vanthienen wrote:
o use such fL.S.,
As suggested by a lot of people over the past week , we should focus
on the core assembly before anything else. If we look at the current
ServiceMix 5 project layout, that would mean we have 3 non-core bits
in there that we would need to think about.
The first one is the "activiti" module. This seems to be a pretty
good match for our core technology set. So I would suggest we keep
that around for now, once it moves to a Karaf subproject or (even
better) to the Activiti project itself, we can just reuse that effort
and remove our bits.
The two things we do may want to remove are the "akka" and "logging"
modules.
The "akka" bits are a personal experiment of mine and I'm not sure
anyone is using that at all. Also, that technology is probably a bit
alien to a lot of people in the community, so it probably makes no
sense keeping it around. I would propose we just remove that
entirely.
For "logging": I doubt a lot of people are using that as well. I was
first thinking of adding a demo using Camel Pax-Logging instead, but
that seems a bit harder than I expected. Regardless, this is another
module where we should ask ourselves whether we want to keep it around
(for now) or not.
Regards,
Gert Vanthienen
--
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.sobkow...@gmail.com <mailto:krzys.sobkow...@gmail.com> |
Twitter: @KSobkowiak
--
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.sobkow...@gmail.com <mailto:krzys.sobkow...@gmail.com> |
Twitter: @KSobkowiak
