karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Red Hat" <bradj...@redhat.com>
Subject RE: Karaf IoT
Date Mon, 02 Jan 2017 14:45:52 GMT
If I get a bit of time perhaps I'll try to create at least a skeleton/basic reference implementation
for what I have in mind.  While I like the idea of the Kura project I'm not thrilled with
some of what I saw.  I'd like to be clear that I don't think the Kura project is bad, per
se, but it looks like it was built bottom up and it is heavily Eclipse based. That there are
bundles with JNI bindings is fantastic and I'm very thankful that someone has done that heavy
lifting.  But C++ is leaking up into the Java code. I recognize that Kura is focusing on the
low level necessities. So higher level abstractions like service interfaces like LED, CANBus,
USB, and so on aren't practical.  At least not yet. So to some extent this is about Karaf/Felix
and the relevant Maven plugins but it is also about abstracting away the underlying JNI into
more OSGi service focused implementation. The developers on the Kura project obviously know
their sh*t when it comes to the low level board and driver code, the JNI wrapper code and
the like.  Kudos to them.

Kura is a great project but it simply doesn't fit the way I'm used to working with OSGi and
much of it doesn't seem coded with an OSGi-centric view of the world.  Having said that, the
bundles they've created to hook into hardware can be leveraged in a Karaf/Felix environment
easily enough. And relevant OSGi service centric implementations can be created. If Kura didn't
exist I probably wouldn't even contemplate a Karaf/Felix project. Having bundles that are
pre-compiled for things like CAN are marvelous.  For that level of library it really doesn't
matter how the OSGi bundle was created since it is simply a plain ol' OSGi bundle asset (Pooba).


I'm getting set up to work on IoT/small devices and since I've worked with Karaf/OSGi for
the past 5 years it was the obvious starting point.  Since I've been using Karaf and Aries
I'm used to those Maven plugins. There are a number of aspects of Kura that bothered me in
the hour or so I looked at the project. There isn't one single thing that was a non-starter,
it was more an aggregate. So choosing any single point in the abbreviated list below isn't
really germane. This isn't a complete list by any means.

--I'm not a big fan of Tycho or the Eclipse OSGi "plug-ins" (not to be confused with the Maven
plugins). 
--Doing Manifest first implementations are workable, of course, but I don’t find it desirable
and it doesn't mesh with my preferred approach.
--While I use the Eclipse IDE I don't want to use its mechanisms and GUI for the implementation
mechanics.  Sure I can work around that but I'd prefer to not even start there.
--The DS examples used XML for configuration and I didn't see any examples of annotated classes.
XML is a perfectly valid mechanic, of course.
--Almost all of the Java code samples use Hungarian notation. Not evil in and of itself but
I do consider it a code smell. If something as fundamental as camel casing isn't being used,
what is the likelihood that higher level abstractions are being used in a real Java/OSGi fashion.
(I can't answer that question as I didn't dig in enough but I wasn't encouraged).
--Not surprisingly many of the calls looked low level - writing hex values. To me those should
be mapped values in configuration files while the OSGi service interfaces provide more human
friendly method calls.
--A lot of casting that looks like Java 1.4 without the use of generics.
--Many of the I/O libraries are third party in any case and not specifically written for the
Kura project - CAN, HIDAPI, USB, for example.
--As stated previously I think the Karaf 4 profile compilation and zip makes it an ideal way
to create and deploy a project.
--Ant (comfortable for someone coming from Make I'd guess). Personally I never want to go
there again.
--No fluent APIs.
--No annotations used to simplify coding
--Static method calls that should be abstracted away.
--Etc.

On that last point I think the prime example I saw was the DeviceManager from J2ME be called
directly to get GPIO, I2C and SPI devices. That reach across the OSGi classloaders to couple
with a concrete implementation isn't in the spirit of OSGi really. At some point that DeviceManager
or other mechanism must be called.  But will it always be the DeviceManager from J2ME? Things
like GPIO, I2C and SPI already have interfaces in the J2ME implementation.  So OSGi services
like GPIOConnectorService, I2CConnectorService and SPIConnectorService make a great deal of
sense. A developer using those services would be unaware of the underlying mechanism.

http://docs.oracle.com/javame/8.0/api/dio/api/index.html

A great set of interfaces with a few implementation classes and factories. This is one of
those cases where I think a more OSGi compliant way to do this would be to create things like
the connector services mentioned above and then hide the DeviceManager in the *.internal package
in the bundle. The services could be used to configure the devices or better yet, the bootstrap
and configuration could use the connector service to instantiate the device interface and
make it available via a service factory.  The GPIO pin is a good example.  Since that is already
an interface the service factory could simply provide it preconfigured via injection into
a developer's code.

Obviously those last points aren't specifically about Karaf/Felix or Equinox.  But it is the
sort of expected OSGi abstraction that I'm not really seeing. It is that OSGi service thinking
that I'm not seeing in the project.  I'm sure the Kura project would be amenable to some of
those changes.  But as I said up front, my concerns aren't about any single aspect.

Brad






-----Original Message-----
From: Markus Rathgeb [mailto:maggu2810@gmail.com] 
Sent: Monday, January 2, 2017 6:03 AM
To: user@karaf.apache.org
Subject: Re: Karaf IoT

Hi,

> I'm not really an expert, but I know the openHAB project, which AFAIK 
> uses Eclipse Kura, is based on Karaf.

openHAB 2 is using the Eclipse SmartHome framework.
openHAB 2 is running on Karaf.


Mime
View raw message