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:[email protected]] Sent: Monday, January 2, 2017 6:03 AM To: [email protected] 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.
