karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Karaf IoT
Date Mon, 02 Jan 2017 11:11:58 GMT
Hi Brad,

I'm not really an expert, but I know the openHAB project, which AFAIK uses
Eclipse Kura, is based on Karaf.
At least version 2.0 is. Maybe this can also be a pointer for you to look
at.

regards, Achim

2017-01-02 1:37 GMT+01:00 Brad Red Hat <bradjohn@redhat.com>:

> I was looking at the Kura project for future development and a move toward
> IoT development.  Unfortunately I have several issues with the project
> which are not going to be solved by simply becoming a contributor.  It made
> me wonder if there’s been any discussion about a similar project using
> Felix/Karaf/Camel/Maven and related plugins? It isn’t even that the
> projects necessarily need to be competitive.  Many things like driver
> libraries could be shared. Since the Kura drivers should already bundles
> repurposing or simply using them shouldn’t be that difficult.
>
>
>
> There are a few aspects of a Felix/Karaf/Aries that lend themselves to
> such an implementation.  The Karaf 4 profiles mechanics are a perfect
> mechanism for creating a testable, self-contained application that can be
> run on a developers machine during development and then the zip file can be
> moved to whatever device one is working with and unzipped.  That’s about as
> easy an installation as I can think of.  Since that minimalist karaf 4
> implementation is so small and the provisioning is static at compile time
> it hits the nail on the head.  When I put together a project recently and
> included CXF and a number of other libraries the whole thing was about 30MB.
>
>
>
> The PAX CDI mechanisms make wiring up beans and routes a lot easier.  That
> certainly could make writing applications for small devices a lot easier.
>
>
>
> Just one simple example from the sample code:
>
>
>
> GPIOPinConfig pinConfig = new GPIOPinConfig(
>
>                DeviceConfig.DEFAULT,
>                                               //GPIO Controller number or
> name
>
>                17,
>
> //GPIO Pin number
>
>                GPIOPinConfig.DIR_INPUT_ONLY,
>                                                          //Pin direction
>
>                GPIOPinConfig.MODE_INPUT_PULL_DOWN,
>                               //Pin resistor
>
>                GPIOPinConfig.TRIGGER_BOTH_EDGES,
>                               //Triggers
>
>                false
>
> //initial value (for outputs)
>
> );
>
>
>
> GPIOPin button = (GPIOPin) DeviceManager.open(GPIOPin.class, pinConfig);
>
>
>
> Seem to beg for OSGi services (DS or blueprint), annotations, and simple
> cfg files. Something like that GPIOPin or even a GPIO connector could
> really be injectable OSGi services with all the configuration tucked in the
> cfg or with defaults in blueprint properties or DS annotations. Somehow I
> suspect the DeviceManager is not a service factory but I didn’t dig in.
> There were too many parts of the project that really didn’t appeal to me.
>
>
>
> In any case, there’s probably some discussion about this already.
>
>
>
> Brad
>
>
>
>
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Mime
View raw message