I hesitate to suggest this since I don't have any time to help implement it, but IIUC some of this is suggestions that other projects maintain karat style features. The osgi subsystems spec is complete and the aries implementation works so perhaps integrating it into karaf and using spec subsystems or features would be a better long term goal.
thanks david jencks On Feb 24, 2014, at 11:42 AM, Gert Vanthienen <[email protected]> wrote: > L.S., > > > Time to tally up the score here: > > 1/ So for Activiti, we seem to agree to keep it around for now and > just see if we can eventually move that elsewhere. > > 2/ Akka appears to get some mixed votes. I agree it's interesting > technology that might come in handy sometimes, that's why I added it > in the first place, but I'm not sure we should be maintaining that > code. Perhaps we should just keep the example around and base it on > the stuff that's provided by the Akka project itself - they no longer > have support for Blueprint to bootstrap Akka, but they do have an > Activator-based solution available. If that makes sense to everyone, > I'll raise a JIRA issue for it. > > 3/ Finally, the logging bits. Just for clarity: it is a > PaxLoggingAppender implementation that sends log messages to a JMS > queue or topic, meant to be an easier to use, purely OSGi-based > alternative to the default Log4J JMS appender. For that one, it seems > most people prefer to keep that around as well. > > > Regards, > > Gert Vanthienen > > > On Sat, Feb 22, 2014 at 1:20 PM, Achim Nierbeck <[email protected]> > wrote: >> Hi, >> >> 1) I also agree keep it along as long as it's not maintained by activiti, >> which could mean forever since the aries feature is part of karaf also ... >> :) >> >> 2) might be interesting to keep around, but how about as an optional - more >> standalone like - feature >> >> 3) what's the difference to pax-logging? I really need to take a closer >> look on this .... >> >> regards, Achim >> >> >> >> 2014-02-21 23:16 GMT+01:00 Filippo Balicchia <[email protected]>: >> >>> Hi, >>> >>> 1: for activiti i think the solution is would be do it at Activiti. >>> Like other projects like Cxf, Camel and Activemq provides their features >>> and module osgi compatible >>> >>> 2: Akka. I'm not agree to remove it cause from my point of view can be >>> useful in >>> Batch processing solution or or domain like online-gaming or finance and >>> not only obviously. >>> Have a package ready for a service environment can be convenient. >>> >>> Said That, I don't know how far It can serve in an integration platform. >>> >>> 3: For logging I'm fully agree with Jb >>> >>> Regards >>> >>> --Filippo >>> >>> >>> 2014-02-21 19:47 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: >>> >>>> Hi Gert, >>>> >>>> I agree: >>>> >>>> 1/ for Activiti, ok to keep it in ServiceMix for now. The best would be >>> to >>>> do it at Activiti. >>>> 2/ ok to remove akka. >>>> 3/ for logging, we can keep it in ServiceMix for now. >>>> >>>> Regards >>>> JB >>>> >>>> >>>> On 02/21/2014 06:02 PM, Gert Vanthienen wrote: >>>> >>>>> L.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 >>>>> >>>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> [email protected] >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>> >> >> >> >> -- >> >> 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/>
